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Preface 


This book is for Computer Science and Engineering undergraduate students which is 
simple to comprehend and is especially written in the format these students would 
enjoy reading and benefit from learning the foundation concepts of Software 
Engineering. It has been integrated from various resources including but not limited to 


the following titles: 


[1] Roger S Pressman, Software Engineering- A Practitioner’s Approach, McGraw Hill, 7" 
Edition, 2010 


[2] Ian Sommerville, Software Engineering, Addison-Wesley, 9" Edition, 2011 


[3] Douglas Bell, Software Engineering for Students — A Programming Approach, 
Addison-Wesley, 4°" Edition, 2005 


Organization of the Book 
The book is organized into nine chapters and two Appendices. 


In the first introductory chapter, we become familiar with professional software 
development that would consist of people developing software products including code, 


programs and documentation. [2,3] 


In chapter 2, we are concerned with Requirements Engineering introducing user and 
system requirements. The former tells the system users what service the system will 
provide while the latter defines system’s functions, services and constraints in greater 
detail. In this phase, a requirements specification is also developed for users describing 


their view of the system, and expressed in natural language. [2,3] 


The third chapter on Design is lengthy taking into account all possible types of system 
designs such as User Interface Design, Modularity, Architectural-Based Design, Pattern- 


Based Design, WebApp Design, Navigation Design, Component-Level Design, Object- 


Oriented Hypermedia Design Method (OOHDM), Object-Oriented Design using UML 
(Unified Modeling Language) as well as Data Flow Design. [1,2,3] 


Chapter 4 deals with software processes such as Waterfall Model, The Spiral Model, 
Prototyping, Incremental Development, Open Source Software Development, Agile 


Methods and Extreme Programming and the Unified Process. [1,2,3] 


Chapter 5 describes the Project Teams in respect of the principles behind the teams 
working, how functional and project teams operate and finally how the chief 


programmer team operates. [3] 


Chapter 6 is about Software Metrics and Quality Assurance. Metrics or measures applied 
on software will help us determine the quality of software, monitor and improve the 
software as well as they are helpful for assessing different software development 
approaches. Quality assurance is similar in that monitoring and controlling the process 


of a software development system helps meet its quality goals. [3]. 


Chapter 7 portrays about Project Management on the overall. It is an activity trying to 


verify that the software development is successful. [3] 


Chapter 8 summarizes software testing. Testing is done to ensure that the software 
does what it is intended to do and to discover any defects the program has before 


putting it to use. [2] 


Chapter 9 goes on to explain software evolution. As a matter of fact, software 
development does not stop after it has been developed but continues to evolve 
throughout the lifetime of the system. [2] 


Last comes the Appendix section. There are two short appendices A and B. Appendix A 
considers several short sample case studies on software engineering. Appendix B 


illustrates a UML summary showing the basic concepts and notations. [3] 
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CHAPTERI1 


Introduction 


1.1 Professional Software Development 

Teams rather than individuals develop software products such as for integrating in 
other devices or in the form of information systems or CAD systems etc. The entire 
system not only consists of software products but also documentation aided by other 
programs, guides and data to make the whole system in the process of professional 
software development. An amateur software development would consist of an individual 
developing software for his needs without documentation and guides but a fully 
professional software development would consist of people developing software 


products including code, programs and documentation. 
There are two kinds of software products that software engineers develop. They are: 


Generic Products: These are stand-alone systems designed to meet customers’ needs 
generally who are able to buy them. They include databases, word processors, drawing 
packages, and project-management tools. Software products in this category also 
include library information systems, accounting systems, or systems for maintaining 


dental records, which are designed for a specific purpose. 
Customized Products: These are systems that are tailored according to the needs of a 
particular customer. Examples of such software products include control systems for 


electronic devices or systems to support a particular business process. 


The specific set of attributes you would like to expect from a software system are 


summarized below: 


Maintainability: There should be scope for software change in a changing business 


environment. 
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Dependability and Security: Dependable software should be reliable, secure and 


safe. They should not damage physically or economically in the case of system failure. 


Efficiency: Software efficiency includes responsiveness, processing time and memory 


utilization. 


Acceptability: Software should be acceptable which means they should be 


understandable, usable and compatible with other systems the users use. 


1.2 Software: Problems and Prospects 
The problems centered around software development and the goals software 


developers seek to achieve are: 


e meeting users’ needs 
e low cost of production 
e high performance 

e portability 

e cost of maintenance 

e high reliability 


e delivery on time 


Meeting users’ needs: 
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It is obvious that software engineers should build products according to their clients 
needs but all along evidence has shown that 2% is only used as delivered. This shows 
that requirements engineering or analysis should play an important role in the whole 
process rather than reliability or cost. However, it should be taken into account that 


smaller systems can be tailored to serve clients’ needs better. 
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Cost of Software Production 


Industrialized nations spend on software development in significant proportions. The 
cost of software is influenced by the productivity of the software developers and their 
salaries. The performance of these software developers is dependent not only on their 
ability to code but also to carry out clarifying the problem specification, software design, 
coding, testing and documentation. It is sort of difficult to predict how much time a 
piece of software will take to develop and hence the cost and delivery date of software 


is also affected. 


In the early days of computers, hardware was costly and software relatively cheap. 
Nowadays due to mass production and miniaturization, hardware is cheap and software 
costly. For instance in 1955, software cost only 10% of about a project while hardware 
cost 90%. Nowadays software has risen to about 90% of a project’s cost, while the 
remaining 10% cost comprises hardware. These proportions should be treated 


carefully. They hold for certain projects only and not in each and every case. 


Some software is simple and easy to write but most commercially used software is large 
and extremely complex. Clearly, the cost of testing is enormous, whereas coding 


constitutes only a small part of software development. 


In summary, what we see today is that software is expensive: 
e relative to the gross national product 
e because developers exhibit apparently low productivity 
e relative to the cost of hardware 


e in popular perception. 


Software Performance 
Examples of software performance include: 


e an interactive system responds within a reasonably short time 
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e acontrol signal is output to a plant in sufficient time 
e agame runs sufficiently so fast that the animation appears smooth 


e a batch job is not taking 12 hours when it should take one. 
Portability 


Software should be portable from one hardware to another and that is what is expected 
given the advent of high-level languages and international standards. But that’s not 
actually the case because clients are tied to their suppliers for switching allegiance at a 


considerable cost in converting software. 
Maintenance 


This factor comes into the picture after a piece of software has been written and put 


into operation. There are two types: 


1) Remedial Maintenance: The software is tested for faults or bugs. 
2) Adaptive Maintenance: The software is modified either because the user’s needs 
have changed or the computer, operating system or the programming language has 


changed. 
Reliability 
A software piece is reliable if it keeps working and working without undesirable 
malfunctions. 


Now we need to coin three terms that would make a software piece undesirable: 


1) Error : a wrong decision made during software development. 
2) Fault: a problem or bug causing software to malfunction. 


3) Failure: an event causing software to malfunction. 


An error is a mistake causing one or more faults in software. Failure will result while the 
system is tested. Failures are symptoms that end-users experience while faults are what 


the developers have to solve. 
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Delivery on Time 


The fewer faults or bugs a software piece has, the higher the chances that it will be 


delivered to the client on time. 


1.3 Software Crisis 


A software crisis arises when: 


e it fails to do what users want it to do 

e itis expensive 

e it isn’t always fast enough 

e it cannot be transferred to another machine easily 
e itis expensive to maintain 

e itis unreliable 

e itis often late 


e itis not always easy to use 


1.4 Remedy: Software Engineering 
There are problems in developing software and so what is the remedy? A number of 
methods and tools comprising software engineering is the likely answer. Some of them 


are as follows: 


e greater emphasis on carrying out all stages of development systematically. 

e computer assistance for software development — software tools. 

e an emphasis on finding out exactly what the users of a system really want 
(requirements engineering and validation) 

e demonstrating an early version of a system to its customers (prototyping) 

e use of new, innovative programming 

e greater emphasis on trying to ensure that software is free of errors (verification). 


e incremental development, where a project proceeds in small, manageable steps. 
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1.5 Software Engineering Ethics 

Like other engineering disciplines, software engineering imposes professional 
responsibilities without pertaining to laws among teams of people working to develop 
software products. These responsibilities cover more than the appropriate application 
of technical skills such as honesty and integrity as well as ethical and moral ways on the 


part of the employees. Some of these responsibilities on a wider range are: 


1) Confidentiality: You must respect the confidentiality of your employers or clients 
although no such treaty may have been signed. 

2) Competence: You should accept work only that you know you have the right skill set 
and are competent. Accepting any other work might end in jeopardy and chaos. 

3) Intellectual property rights: You should be aware of local laws governing intellectual 
property rights such as patent and copyrights and protect those property rights of 
employers and clients. 

4) Computer misuse: You may not mishandle your employer’s computers by applying 
your technical skills. This may range from playing games on their computers, for 


instance, to infecting them with viruses and malware. 
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CHAPTER2 


Requirements Engineering 


Requirements Engineering fall under two categories: User Requirements and System 


Requirements. 


User Requirements are natural language statements and diagrams telling the system 
users what service the system will provide and the constraints under which the system 


will operate. 


System Requirements define the software system's functions, services and constraints 
in greater detail. It should clearly state what should be implemented. It may even 


become the part of the contract between the system buyer and software developer. 


Software system requirements may be further categorized as functional and non- 


functional requirements. 


For instance, functional requirements define what service the system will provide, how 
it reacts to particular inputs and how it should behave under certain conditions. It may 


also mention what the system may not do. 


Non-functional requirements consist of constraints and functions imposed by the system 
such as timing constraints, constraints on the development process and standards- 


based constraints. These may be applied to the system as a whole. 


2.1 How to Elicit Requirements 


We can categorize three activities to elicit requirements: 


1. Listening 
2. Thinking 
3. Writing 
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Listening involves the users’ needs or requirements of the system, asking them about 
goals and constraints of the system and finally recording their viewpoints of the system 


requirements. 


Requirements analysis is the level where the system simply thinks. S/he transforms the 
users’ view of the system as an organized representation of the system as seen by the 


analyst. 


Requirements definition is a clear statement, usually in natural language, of what the 
system should actually provide for its user. This definition translates into a requirements 


specification. 


2.2 Requirements Specification 
Three important factors to be considered are: 
e the level of detail 

e to whom the document is addressed 


e the notation used 


The specification, as we have already mentioned, should tell in detail the user’s view of 


the system rather than how the system should be implemented. 


The specification is a contract between users and developers. While users will prefer it 
in natural language, developers would like to use some mathematical notations to be 


more precise. This problem can be resolved by drawing up two documents. These are: 


e A requirements specification written for users, describing their view of the system 
and expressed in natural language. This is the substance of the contract between 
the users and the developers. 

e A technical specification that is used by developers, expressed in some formal 
notation and describing only a part of the information in the full requirements 


specification. 
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2.3 Structure of a Requirements Specification 


Simply put, a requirements specification consists of functional and non-functional 


requirements as we have mentioned earlier. 
Functional requirements state what the system should do. 


Non-functional requirements consist of: 


e Data Requirements 
e Performance Requirements 
e Constraints 


e Guidelines 
Let us look at each of these by turns. 
Data Requirements consist of three parts: 


e User’s data being input or output via screen, keyboard or mouse. 
e Data that is stored in files on the disk within the system 


e Exchange of information between computer systems 


Performance Requirements are usually measures of performance 


quantitatively, which may also be used in part for testing. These can be 


e Cost 

e Delivery time 

e Response times 

e Data volumes 

e Loading levels that can be accommodated 
e Reliability requirements 


e Security requirements 
Constraints are influences on the implementation of a system. 


They define conditions on items such as, 
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used 


e The amount of hardware that is to be used 

e The amount of memory available 

e The amount of backing store available 

e The programming language to be used 

e Interoperability constraints such as a software piece running mandatorily under the 


latest version of Windows. 


Guidelines provide useful information for applying an implementation strategy to a 


situation. 


2.4 Use Cases 
One popular method to document requirements is by using UML (Unified Modeling 
Language) use case diagrams. A user in a use case is an actor carrying out a task. The 


use case is the action carried out by the user/actor. It tells what the system should do. 


For instance, in the case study of ATM system, the user withdraws cash. The use case 


for withdrawing cash is: 


withdraw cash. The user inserts their card. The system prompts for the PIN. The user 
enters the PIN. The system checks the PIN. If the card and PIN are valid, the system 
prompts the user for their action. The user selects dispense cash. The system prompts 
for the amount. The user enters the amount. The system ejects the card. When the 


user has withdrawn the card, the system dispenses the required cash. 


A set of use cases constitutes the functional specification of a system. Use cases can 
also be used to: 

e derive the software structure 

e create test cases 

e help write a user manual 


e predict software cost. 
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2.5 Use Case Diagrams 

We can document a use case such as an UML case diagram but it does not contain the 
detail as a textual use case. However, it does give the big picture of the actors and use 
cases. So in this sense it provides an informal representation of user requirements in 
the system. 

The figure 2.1 shows an example of a UML case diagram. The actor is a bank customer 


and his roles (use case functions) are withdraw cash and check balance. 


withdraw cash 


ee 


bank customer CD 


check balance 





Fig 2.1: Use Case Diagram for the ATM 
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CHAPTERS 
Design 


3.1 User Interface Design 


So far there have been three types of interface: 1) command-line 2) menu 3) GUI 
(graphical user interface) which tell the users what they would want the computer 


interface to do. 


In the early days of computing, the only mode of human computer interaction was 
command-line interface. Communication was driven by commands or responses to 
system-generated queries. For example, you can instruct the command-line interface to 
delete a file by using the following command: 

del c:\file1.txt 


The command-line is further developed to form a menu. For example, a menu can contain 
the following choice of commands: 
To delete the file, press key D 
To display the file, press key L 
To open a file, press key O 
To save the file, press key S 
Menu-driven systems have advantages over command-line interface. For instance, 
1) Users don’t have to know or remember commands 
2) User errors are avoided 


3) Syntax errors are prevented. 


As hardware became more sophisticated and software engineers became more familiar 
with human factors and their impact on interface design, the modern window oriented 
pick and point interface evolved resulting in GUI or WIMP (windows, icons, menus and 


pointing devices). Such an interface presents the user with a set of controls or widgets 
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such as buttons, scroll bars and text boxes. Instead of typing an option, the user makes a 


selection using a mouse button. 


The advantages of GUI include: 

1) They are relatively easy to learn and use. 

2) The user can use multiple windows for interacting with the system 

3) Fast full-screen interaction is possible 

4) Different types of information can be displayed simultaneously, enabling the user to 
switch contexts 

5) The use of graphical icons, pull-down menus, buttons and scrolling techniques reduce 


the amount of typing 


3.1.1 The Golden Rules 

Theo Mandel in his book on Interface Design defined three golden rules: 
1) Place the user in control 

2) Reduce the user’s memory load 


3) Make the interface consistent 


Place the user in control 
As a designer you may be allured to using constraints and limitations on your interface 
design which makes it easy to develop but difficult to use. Mandel defines a number of 


design principles that help the user to maintain control. These are: 


1) Define interaction modes in such a way that does not force a user to take undesired 
actions. 

2) Provide for flexible interactions: Because different users prefer to interact in different 
ways, choices should be provided. 

3) Allow user interaction to be uninterruptible and undoable: Even when the user is 
involved in a series of interactions, he should be able to interrupt and do something 


else without losing any of his work and also have the option of “undo”. 
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4) Allow the skilled user to customize interaction: Skilled users may often find that they 
have to use the same set of interactions repeatedly. It then becomes necessary on the 
part of the skilled user to use a “macro mechanism” to customize the interface for fast 
interaction. 


5) Hide technical details from the novice user: The novice user should never be aware of 
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the internals inside the machine while interacting with the interface, such as, operating 
system or file management functions and others. 
6 


NY, 


Design for direct interaction with objects on the screen: The user feels a sense of 
control when they are able to manipulate objects to do tasks as if they were physical 
things. 


Reduce the user’s memory load 
A well-designed interface doesn’t require the user to remember a lot because then he 
would become more error-prone while interacting with the system. Mandel defines design 


principles that enable an interface to reduce the user’s memory load: 


Reduce demand on short-term memory: When users are involved in complex tasks, the 
demand on short-term memory can be huge. The interface should be designed in such a 
way to reduce the memory load to remember past actions, inputs, and results. Visual cues 


in this case might help without having to recall. 
Establish meaningful defaults: The average user should be able to make sense out of 
original default settings. However, he should also be able to re-specify his own 


preferences for default values. 


Define shortcuts that are intuitive: When shortcuts are defined for functional operations, 


they should be tied to the action that is easy to remember. 
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The visual layout of the interface should be based on a real world perspective: For 


example, a bill payment system should use a checkbook and check register based on real 


world visual cues so that it is easy for the user to understand rather than memorize. 


The interface should be organized hierarchically: That is, information about a task, an 


object, or some behavior should be presented first at the highest level of abstraction. 


More detail should be presented after the user indicates interest with a mouse click on a 


particular level. 


Make the interface consistent 


The interface should present and acquire information in a consistent manner. Mandel 


defined the following principles for making a consistent interface: 


1) 


2) 


3) 


Many interfaces present complex layers of interaction with many screen images. 
Window titles, graphical icons and color coding should enable the user to recognize 
the context of work at hand. He should know which task he was working and 
transition to newer tasks smoothly. 

Maintain consistency across a group of applications. A set of applications (or 
products) should all implement the same design rules so that consistency is 
maintained for all interaction. 

If past interactive models have met user expectations, do not make changes unless 
there is a definite reason to do so. Once a particular interactive sequence has 


become a particular standard, the user expects this in every application he uses. 


3.1.2 Users of an Effective Interface System 


The various users of an effective interface system can be categorized as follows: 


Novices: These are users who have no syntactic or semantic knowledge of the 
system and while they are inexperienced, they are also newbies. 
Knowledgeable Intermittent Users: They have a significant amount of syntactic 


knowledge of the system but it is not enough to recall in moments of need. 
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e Good Frequent Users: They have good semantic and syntactic knowledge of the 


system and are more likely to use shortcuts and abbreviated modes of interaction. 


3.1.3 Interface Analysis 

With reference to interface system design, understanding the problem means 
understanding: 

e end users who will interact with the system via the interface 

e the tasks end users must perform 

e the content that is used as part of the interface 


e the situation where these tasks will be carried out 


3.1.4 User Analysis 

In order to bring in line the system’s mental image and design model of the user, the 

software engineer has to understand the users themselves and how they will use the 

system. For this to happen we need to collect information from a wide spectrum of 
resources. Some of these are: 

e User Interviews: This can happen through discussion between software engineers 
and users on latter’s needs, motivations and their kind of work. This can go for one- 
to-one correspondence or even brainstorming sessions among groups. 

e Sales Input: Sales people meet users regularly and gather information regarding 
their requirements and convey them to software developers. 

e Marketing Input: Market analysis might use the software in their different 
segments and an understanding is required about how this helps. 

e Support input: Support staff talk with users regularly and they are most likely to 
find out what works or what doesn’t, what they like or dislike or which features are 


unknown or familiar to them. 


3.1.5 Task Analysis 
In order to carry out task analysis, we are presented with some questions: 


e What work will the user carry out in specific situations? 
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e What tasks will be executed as the user carries out the work? 


e What specific problem domain objects will the user manipulate as work is carried 
out? 


e What is the sequence of work tasks—the workflow? 


e What is the hierarchy of tasks? 
To answer these questions, use the techniques discussed in sections 1.2, 1.4, 1.5, 2.2, 


2.3, 2.4, 2.5 and previous subsections in 3.1 earlier in the book. 


3.2 Modularity 

Modularity has to do with the structure of software. It is the end product of several 
design methods such as, functional decomposition, object-oriented design, data 
structure design and others. It can be considered as the sum total of several 
subsystems or components that are as separate as possible from each other. This is the 


foundation of modularity. 


The guidelines described later in this section should be able to answer questions as 
follows: 

e how large should a component be? 

e is this component too complex? 


e how can we minimize interactions between components? 


A component results from any current or future mechanism where software is divided 
into manageable portions. In various programming languages, a component is a 
method, class or package. But in this chapter, we will relate component to manageable 


portions. 


3.2.1 Component Types 


Components can be categorized as follows: 
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e computation-only 

e memory 

e manager 

e controller 

e link 

A computation-only component has no data between subsequent calls. A math 
method can be an example. 

A memory component is an assembly of durable data. Durable data are those that be 
stored as backup in disks for example, a database or file system. 

A manager data can be an abstract data type such as a stack or queue and their 
operations. 

A controller component can initiate other components and manage interaction among 
them. 

A link component transfers information from one component to another. User 


interface and network software are examples. 


3.2.2 Component Complexity 


What should be the size of a component? It can be constructed in one of the following 


ways: 
® With small components only 
e With large components only 


With small components, each one of them has very few lines of code so that the 
complexity of each is significantly low. On the other hand, complexity in this structure 
arises from the innumerable number of small components. 

However with large components, the structure is simple in the number of components 
which is only a few but within each component, the complexity is high due to the vast 
number of lines of code. 

So which structure is preferable? Actually both. For a piece of software, large 
components are needed during design and maintenance while small components during 


debugging. The less complex a component is, the easier it is to understand it and 
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therefore the smaller size of the component helps. While one component is being 
studied, we do need to keep track of what other components might be doing. This is 
where a level of abstraction is useful in the structure of software so that while we study 
other components about what they do, we do not need to understand how they do it. 
So we can focus only on one component at a time, other components being separate. 
After examining one component, we can take our attention to the next. So what is 
actually important here is the size and complexity of the components and _ their 


interactions. 


Why should we keep a program simple? Here are a few solutions: 


e it is quicker to debug a simple program 

e it is quicker to test a simple program 

e a simple program is more likely to be reliable 
e it is quicker to modify a simple program. 


How does a good engineer maintain complete control and understanding over all the 
components of the project? The answer is by adhering to the simplicity of each 
component, keeping the few lines of code within them simple. There may be several 
arguments on this approach but this is really the solution everything boils down to. 





Fig 3.1 : Alternative Software Structures 
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3.2.3 How Global Data is Harmful 


Within a component, data can be local or global. Keeping data global means all 
components within a piece of software access these data so that when we need to 
understand or examine a component, other components depending on the same data 
will have to be studied. This means separation of components or modularity is not 
rightly achieved. 


On the other hand, if data is local for instance, within a method (which is, in fact a 
component), those data will be accessed by those components only. So in this case, a 
high degree of separation or modularity is achieved. However, these local data can be 
passed around the program as parameters. 


In general, local data is preferable because: 

e it is easier to study an individual component because it is obvious what data the 
component is using. 

e itis easier to remove a component and place it in a new piece of software, because 
it is a self-contained package. 

e the global data, if any, is easier to study because it has been reduced in size by 
making most of the data local to the various methods. 


Summing up, in a software structure, the amount of global data should be minimized 
while that for local data should be maximized. 


3.2.4 Information Hiding 

Information hiding or encapsulation helps to structure software, giving it a great 
modular design. Considering a data structure or file structure, its structure itself and the 
statements that access or modify the structure are all part of a single component. A 
piece of data encapsulated like this cannot be accessed directly but only via one of the 
methods associated with the data. Such a collection of data and methods is called a 


class or object in object-oriented programming. 


Information hiding can be utilized by using a stack concept. Methods push item onto 


the stack top and pop items from the stack top. Given this illustration, the stack 
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implementer can make use of an array, linked list etc. while coding. However, the user 


of the stack does not need to know how the stack is implemented. 


Information hiding meets three criteria: 

1) Modification 

When the design of a file structure for instance, is needed to be modified, as few 
components as possible are taken into consideration and ultimately modified. Preferably 


as much as possible, only one component will just be changed. 


2) Simplicity 

When the system is developed by a team of programmers, care should be taken that 
the interfaces among the components are as simple as possible. Information hiding 
actually asserts that interfaces are actually calls on methods which are definitely simpler 


than accesses to shared data or file structures. 


3) Independence 
For design, checking, testing and maintenance, we need to study the components as 
independently as possible. Information hiding makes this possible while shared or 


global data will not. 


3.2.5 Coupling and Cohesion 

Alternative ways of describing interactions among components and within components 
are coupling and cohesion. A piece of software should ideally be developed from its 
components such that there is minimum interaction among components (low coupling) 
and a high degree of interaction within each component (high cohesion). 

Coupling and cohesion are opposite sides of the same coin. Strong cohesion results in 


weak coupling and vice versa. 
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3.3 Architecture-Based Design 
Architectural-based design consists of the structure of data and program components 
required to build a computer-based system and the interrelationships among the 


architectural components. 


A software engineer can design both the data and architecture but often a huge, 
complex system has to be built so that the work of data is given to a specialist such as, 
a database or data warehouse designer while the architecture is handled by the system 
architect based on the software requirements derived from requirements engineering 


analysis. 


The steps in the architectural design include data design and proceeds with the 
derivations of one or more alternatives of the structure of architectural system. Once an 
alternative is selected, the architecture is extended with an architectural design method. 
The work product of this system is the development of data architecture and program 


structure along with component properties and the interactions among them. 


To make sure the work product is done right, at each stage, the software design work 
product is tested for clarity, correctness, completeness and consistency along with 


requirements among each other. 


3.3.1 Architectural Descriptions 
An architectural description is a set of work products that portray the different views of 


the system. In order to understand this description, look at the following example: 


The architect of an office building must work with various stakeholders. The owner of 
the building (one stakeholder) holds the view that it should be elegant looking and have 
enough space and infrastructure to ensure profits. Accordingly, the architect must meet 


the demands of this stakeholder’s view. The architect does this by drawing three- 
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dimensional views of the big picture of the office building and also, two-dimensional 


views of floor plans covering space and infrastructure. 


Another stakeholder could be a steel structural fabricator who will provide steel for the 
skeleton structure of the building. Among the many details he would require, he needs 
architectural information regarding the steel that will support the building, their 
dimensions, connectivity, materials and many more. Each of these concerns is realized 
by a different work product that outlines a different view of the architecture. One such 


view, for instance, is for the steel skeleton structure of the architecture. 


An architectural description of a software-based system is similar to that illustrated in 


the office building example above. 


3.3.2 Architectural Patterns 
A widely used way of presenting, sharing and reusing knowledge about software 


systems is the idea of patterns. Here I give several examples of architectural patterns. 


1) Layered Architecture 
This pattern organizes the system into layers. Each layer has a related functionality. 
Each of them provides service to the layer above it. Therefore, the lowest layers are 


likely to provide chore services, which will be widely used throughout the system. 


This system is used: 

i) When there is a need to add layers on top of the existing system. 

ii) When the development is involved among several teams, each team working on 
a layer of functionality. 


iii) When there is the need for multi-level security. 
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User Interface 


User Interface Management 


Authentication and Authorization 


Core Business Logic/Application Functionality 


System Utilities 


System Support (OS, Database etc.) 


Fig 3.2: A Layered Architectural Pattern 





2) Repository Architecture 
All the system components get access to all the data in the system that is stored in a 
central repository. These components cannot interact directly but only through the 


repository. 


The following figure shows an example of IDE (Integrated Development Environment- a 
software application that provides comprehensive facilities to computer programmers 
for software development) where components use a repository of software tools. Each 


tool generates information, which can then be used by other tools. 


This system pattern is preferable when large volumes of data are generated and have 
to be stored for lengthy durations. 


Components are independent — one component doesn’t need to know the existence of 


other components. A change initiated in one component can be propagated to all other 
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components. A fault in one component affects other components of the system. 


Distributing the repository across several computers may be difficult. 


UML Code 
Editors Generators 
Design Project 
Translator Repository 


Java 
Editor 


Python 
Editor 
Design Report 
Analyser Generator 


Fig: 3.3: A repository architecture for an IDE 





3) Client-Server Architecture 
In a client-server architecture, each separate server delivers service to a group of 


clients which make use of them. 


This architecture is used when the data in a shared database has to be accessed in a 


variety of locations. 


Servers are distributed across a network while a general functionality for instance, a 
printing service can be available to all clients without being implemented by all services. 
Performance can be unpredictable because of dependence on the network as well as 


system. 
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Internet 


Catalogue Video Picture Web 
Server Server Server Server 


Library ; Film and 
Film Store Photo Store Photo Info. 


Fig 3.4: A client-server architecture for a film library 





4) Pipe and Filter pattern 
Each processing component in the system acts as a filter and carries out a single type 


of data transformation while data flows from one component to another as in a pipe. 


This system is commonly used in data processing applications based on both batch and 


transaction-based processing. 


The system can be executed as a sequential and concurrent system. 


Each transformation must parse its input and un-parse its output to the compatible 


form. 
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Issue ; 
Find Payments Issue Payment eee 
Due Reminder 


Read Issued Identify 
Invoices Payments 


Invoices Payments 





Fig 3.5: An example of Pipe and Filter architecture 


3.332 Application Architecture 

Application systems usually meet a business or organization need. There are many 
types of application systems and sometimes they differ from each other too much. 
Many of these applications although dissimilar have much in common and yet can be 
represented by a single abstract application architecture. This can be shown by the 


following two types of architecture: 


i. Transaction processing applications: They are  database-centered 
applications that process user requests for information and update the information in a 
database. This class of system includes interactive banking systems, e-commerce 


systems, information systems, and booking systems. 


Processing Logic Manager 


Fig 3.6: An example of transaction processing application systems 





36 


2. Language Processing Systems : The best-known language processing 
systems are compilers, which translate high-level language programs into machine 
code. However, language processing systems are also used to interpret command 


languages for databases and information systems, and markup languages such as XML. 


3.4 Pattern-Based Design 
This type of design creates a new application by providing a set of proven solutions to a 


clearly outlined set of problems. 


The software engineer examines each problem and encounters the probable solution by 


consulting one or more patterns repositories. 


Reinventing the wheel occurs all the time in software development but it’s a waste of 
time and energy. You can provide a known solution to a specific problem by examining 
existing design patterns. This helps to move closer to the completion of the design 
faster and adeptly. The problem space is subdivided into specific problems associated 
with software functions and features. Problems can also be organized by type: 


architectural, component-level, algorithmic, user interface, etc. 


3.4.1 Design Patterns 

A design pattern can be visualized as a three-part objective among a certain context, a 
problem and a solution. For software design, the reader should be able to understand 
the environment where the problem resides and look for an appropriate solution for 
that problem. A system of forces such as constraints and limitations influence how the 


problem can be interpreted and how an effective solution can be applied. 


An effective design pattern is found in the following way: 
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1. It solves a problem:- A pattern helps to find a solution, not just abstract principles 
and solutions. 

2. It is a proven concept:- A pattern helps to find a solution with a track record, not 
just theories or speculation. 

3. The solution isn’t obvious:- Many problem-solving techniques such as software 
design techniques and methods generate solutions indirectly. This is how the best 
complex patterns are designed. 

4. It describes a relationship:- Patterns just don’t describe modules. In fact, they 
represent deeper system structures and mechanisms. 

5. It has a human component:- The best patterns serve human comfort or quality of 


life, exhibiting beauty and catering for utility. 


3.4.2 Kinds of Patterns 

One of the reasons software engineers are interested in design patterns is that human 
beings from time immemorial are good at pattern recognition. Without being able to do 
so, we would be frozen in time and space, unable to learn from past experience and 


unable to move forward. 


Now let us focus on three types of patterns relevant to object-oriented design: 


creational patterns, structural patterns and behavioral patterns. 


Creational patterns make the creation, composition and representation of objects. 
They make the mechanism of instantiation of objects within a system easier. 
Structural patterns are associated with how classes and objects are integrated to 
build a larger structure. The fact that they focus on objects suggest techniques for 
combining objects within objects or integrating them into a larger structure. 
Behavioral patterns are associated with problems that focus on the assignment of 


responsibility between objects and also the communication directed between objects. 
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3.4.3 Frameworks 

Patterns themselves may not be sufficient to complete a design.. Sometimes, 
frameworks may be needed to implement the internal skeletal structure of the design. 
A framework is not an architectural design but the skeletal structure with plug points 
(hooks and slots) that enable it to develop a problem-specific domain. The plug points 
enable to integrate problem-specific functionality and classes within the skeleton. 
Patterns and frameworks are differentiated in the following ways: 

1) Design patterns are more abstract than frameworks. 

2) Design patterns are smaller architectural patterns than frameworks. 


3) Design patterns are less specialized than frameworks. 


3.4.4 Describing a Design Pattern Template 

Pattern name: describes the pattern in a short but expressive name. 

Problem: describes the problem the pattern addresses. 

Motivation: describes an example of the problem. 

Context: The environment in which the problem resides including its application 
domain. 

Forces: gives the list of forces that are directed to solve the problem. It also includes 
the constraints and limitations applicable to the problem. 

Solution: describes the probable detailed solution proposed for the problem. 

Intent: describes the pattern and what it does. 

Collaborations: describes how other patterns relate to the solution. 

Consequences: There is a potential trade off that must be considered when the 
pattern is implemented and the consequences of using the pattern. 

Implementation: There must be special issues when patterns are implemented and 
these must be considered. 

Known uses: provides examples of the design pattern in real applications. 


Related patterns: cross-reference related design patterns. 
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3.4.5 Language and Repositories 

When you think of the term language, the first thing that strikes the mind is a natural 
language such as, English, Chinese or Spanish or a programming language such as, 
C++ or Java. In both the cases, the language has a syntax and semantics that 


communicate ideas or procedural instructions effectively. 


On the other hand, a pattern language encompasses a collection of patterns, each 
describing a design template, which are interrelated to solve a problem in the 


application domain. 


In a natural language, words are organized into sentences that give meaning. The 
structure of sentences is described by the language’s syntax. In a pattern language, 
pattern designs show a structured method of good design practices within a particular 


domain. 


Dozens of pattern languages have been proposed for software design. Design patterns 
that are part of pattern language are stored in a web-accessible patterns repository. 
The repository contains an index of all pattern designs, which contains hypermedia links 


that helps the user to understand the network of patterns. 


3.5 WebApp Design 

There are basically two approaches to design: the artistic ideal of expressing yourself 
and the engineering deal of solving a problem for a customer. During the first decade of 
web development, the artistic idea was followed by many developers. Design evolved 


out of an artistic idea as it took its way to WebApp design as it got constructed. 


Design for WebApps includes technical and non-technical activities, creating the look 


and feel of the WebApp and the aesthetic layout of the interface. The overall 
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architectural structure is defined, developing the content and structure that reside 


within the interface and maintaining the navigation within the WebApp. 


Web designers, content designers, graphic designers and stakeholders all participate in 


the creation of a WebApp design model. 


Design allows you to create a model that is assessed for quality and improvement 
before content and code are generated, tests are conducted and a large number of end 


users are involved. 


WebApp design covers six steps that are information driven obtained during 
requirements modeling. First, the content design uses the content model as the basis 
for establishing content objects. Aesthetic design, also called graphic design, makes up 
for the look and feel that the end user sees. Architectural design focuses on the overall 
hypermedia structure based on all content objects and functions. Interface design 
establishes the layout and interaction mechanisms based on the interface. Navigation 
design covers how the end user navigates through the hypermedia structure. 
Component design represents the detailed internal structure of the functional elements 
of the WebApp. 


The primary work product that is designed in the process is a work model that covers 


content, aesthetics, architecture, navigation and component level design issues. 


Each element of the design model is reviewed to disclose errors, inconsistencies and 
omissions. Better solutions are sought for and the degree to which they can better be 


implemented are also examined. 


3.5.1 WebApp Design Quality 
What makes a good WebApp? Individual viewpoints vary. Some enjoy flashy graphics 


while others need simple text. Some desire a lot of information while others crave for 
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an abbreviated presentation. Some like sophisticated analytical tools or database access 
while others will like to keep it simple. The user’s perception of ‘quality’ or ‘goodness’ of 


WebApp will eventually be more important than any technical discussion offered. 


How is WebApp quality attained? The most relevant generic attributes namely, usability, 


functionality, reliability, efficiency and maintainability lead to high quality WebApps. 


Global site understandability 
Online feedback and help features 
Usability Interface and aesthetic features 


Special features 


Searching and retrieving capability 
Functionality <= Navigation and browsing features 


Application domain-related features 


Web Correct link processing 
application Reliability << Error recovery 


quality User input validation and recovery 


Response time performance 
Efficiency == Page generation speed 


Graphics generation speed 


Ease of correction 
Maintainability — ee 





Fig 3.7: Web Application Quality Tree 


The following attributes may be added to web application quality: Security, Availability, 
Scalability, Time to market. 


Security 


The key measure of security and its server environment is to prevent unauthorized 
access and thwart a malevolent attack. 
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Availability 
Availability is the measure of the percentage of time a WebApp is available for use. The 


typical end user expects WebApps to be available 24/7/365. 


Scalability 
It is important to build a WebApp that can handle more and more significant users and 


become even more successful. 


Time to Market 
It is a measure of quality from a business point of view. The first WebApp to address a 


specific market segment often captures a bulk of end users disproportionately. 


3.5.2 Design Goals 

A set of design goals applicable to virtually any WebApp regardless of application 

domain, size and complexity is as follows: 

e Simplicity:- The aphorism “All things in moderation” applies to WebApps. The 
content should be relevant and informative and should use a delivery mode such as, 
audio, video, graphics and text that should be appropriate to the content that is 
being delivered. Look and feel should be pleasing but not too overwhelming (the use 
of too many colors will distract the end user rather enable him to interact). 
Architecture should achieve WebApp objectives in the simplest possible manner. 
Navigation should be straight forward. Functions should be easy to understand and 
use. 

e Consistency:- This design goal should be virtually met by all design elements. 
Content should be constructed consistently. For instance, text formatting and font 
style should be the same across all text documents; graphic design should be the 
same in all color schemes, look and feel and style. Architectural design, interface 
design and navigation mechanisms should be consistent across all design elements. 

e Identity:- The look and feel, architectural and navigational design of a WebApp 


must be consistent with its application domain. The aesthetic design will vary from 
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one group or company to another group or company. The architectural design will 
also vary. Navigation will be organized to meet different objectives. You, along with 
other design contributors, will work to establish an identity for the WebApp. 
Robustness:- The end user expects robust content and function that meets his 
needs as promised by the identity of the WebApp. 

Navigability:- Navigation should be simple and consistent. It should also be 
intuitive and predictable. The user should be able to navigate within the WebApp 
without searching for navigation links or instructions. 

Visual Appeal:- Many design characteristics such as, look and feel of content, 
interface design, color coordination, balance of text, graphics, media along with 
navigation mechanisms contribute to the visual appeal. 

Compatibility:- A WebApp will be used in a variety of environments such as, 
different hardware, internet connection types, browsers and operating systems 


which must all be compatible with each other. 


3.5.3 WebApp Interface Design 


When you interact with a computer-based system, fundamental principles and 


overriding design guidelines apply. 


The end user may enter the WebApp at a home location or the homepage or maybe 


linked into some lower level of the WebApp architecture. Sometimes it is necessary for 


the user to reroute to the home location but if this is not feasible, there should be some 


option of interface navigation features that accompany all content objects. 


To implement navigation features, you can select one of the following: 


Navigation menu:- keyword menus arranged horizontally or vertically that list key 
content and/or functionality. 
Graphic icons:- button, switches or other graphical images that enable the user to 


select some property or specify a decision. 
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e Graphic images:- some graphical representation that provides a link to a content 


object or WebApp functionality. 


3.5.4 Aesthetic Design 

Aesthetic design or graphical design of WebApp contributes to its look and feel 
complementing the technical details. 

Layout Issues 

Every webpage has functional aesthetics, navigation features, informational content and 
user directed functionality. This development is planned during aesthetic design. As 
with aesthetic issues, there is no hard and fast rule when designing screen layouts. But 


a set of general layout guidelines are worth considering: 


e Don’t be afraid of white space: Every square inch of the website may not be 
packed with information. The resulting clutter makes it difficult for the user to 
identify needed information or features and create visual chaos that is not pleasing 


to the eye. 


e Emphasize content: A WebApp page should be 80% content and the remainder 


should be for navigation features. 


e Organize layout elements from top left to bottom right : A webpage should 
be able to be scanned from top left to bottom right. If there is a priority for layout 


elements, they should be placed in the upper left portion of the page. 


e Group navigation, content and functionality within the page : If there is no 
distinguishable patterns within the page, user frustration is going to increase, not 


being able to search the information needed, taking longer time. 


e No need for scrolling bar: Research has shown scrolling bar is not a favorite for 


users. Either reduce content on a page or spread it among multiple pages. 
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e Consider resolution or browser window size when designing layout: A 


design should specify all layout items as a percentage of the available space. 


Graphical Issues 

Graphic design considers the look and feel of a WebApp. The graphic design takes into 
account layouts and proceeds with global color schemes. Text types, sizes and styles 
and supplementary idea such as audio, video and animation and all other aesthetics of 


an application should be considered. 


3.5.5 Content Design 

Content designs mainly focuses two design issues which are handled by individuals with 
different skill sets. First a design representation for content objects and the mechanisms 
required to establish the relationships among each other is developed. The information 
within a specific content object is created. The latter task is implemented by graphic 


designers, copywriters and others who generate the content within the WebApp. 


Content Objects 
A content object has content specific information and implementation specific attributes 


that are specified as part of the design. 


Content Design Issues 

Once all content objects are modeled, the information in each object must be authored 
and then formatted to meet customer’s needs. Content authoring is done by specialists 
in the relevant area who design the content object. This can be done by providing an 
outline of information to be delivered. An indication of the type of generic information 
for instance, descriptive text, graphic images, photographs that will be will used to 
deliver the information needs to be taken into account as well. Aesthetic design will also 


be applied for the proper look and feel of the content. 
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3.5.6 Architecture Design 

The goals established for a WebApp are the content to be presented, the users who will 
visit, and the navigation policy. Architecture design is tied to these goals. As an 
architectural designer, you must define content architecture and WebApp architecture. 
Content architecture focuses on content objects which are structured for presentation 
and navigation. WebApp architecture addresses the application which is structured to 
manage user interaction, handle inter-processing tasks, effect navigation and present 
content. In most cases, architecture design is conducted with aesthetics design, content 


design, interface design and navigation design. 


Content Architecture 

The design of overall hypermedia structure of the WebApp is reliant on the content 

design. Although the user can demand a custom design, there are actually four content 

design structures to choose from: 

e Linear Structures are one type of architectural option in which the sequence of 
interactions with some variation or diversion is common. A typical example might be 
a tutorial presentation in which there are pages of audio, video or graphics which is 
presented only after prerequisite information is presented. The sequence of content 
information is predefined and generally linear. 

e Grid Architectures are an architectural option when WebApp content can be 
organized categorically in two or more dimensions. For instance, we can put two 
different measures on horizontal and vertical dimensions and naviagate the grid 
horizontally at first and then vertically. The WebApp architecture is appropriate 
when highly regular content is available. 

e Hierarchical structures are the most common WebApp architecture. A 
hierarchical WebApp structure is such that it allows flow of control horizontally 
across vertical branches of the structure. 

e Network structure is similar to the structure created for object-oriented systems. 
The architectural content or web pages in this case are designed so that they may 


pass control via hypertext links to every other component in the system. 
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The overall architecture of a WebApp can be composite meaning it can be hierarchical 
while a part of it can show linear characteristics and another part can be networked. 
The goal as an architectural designer is to match the WebApp to the content to be 
presented and the processing to be executed. 


Schematic representations all the above representations are shown below: 


optional flow diversions 





Fig. 3.8 : Linear Structure 
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Fig. 3.11: Network Structure 


3.6 WebApp Architecture 
A three layer architecture is appropriate for WebApp that decouples interface from 
navigation and application behavior. This is because keeping interface, navigation and 


application separate simplifies implementation and reuse. 


The Model-View-Controller architecture is one of the WebApp infrastructure models that 
decouple user interface from WebApp functionality and informational content. The 
model contains all application-specific content and processing logic, including all content 
objects. Access to all external data/information sources and all processing functionality 
that is application specific falls under this category as well. A schematic representation 


of the MVC architecture is shown below. 
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Manages user requests 
Selects model behavior 
User Selects view response Behavior request 
request (state change) 
or data View selection 


Model 

Encapsulates functionality 
Encapsulates content objects 
Incorporates all WebApp states 








Update request External data 


Prepares data from model 
Request updates from model 
Presents view selected by 
controller 








Fig. 3.12: A Schematic Representation of MVC architecture 


3.7 Navigation Design 

Once the WebApp architecture is established and the components such as, pages, 
scripts, applets and other processing functions have been identified, you must design 
navigation pathways that help users to access WebApp content and functions. In order 
to meet this goal, we should 1) identify the semantics of navigation for different users 


of the site and 2) identify the syntax of achieving the navigation. 


3.7.1 Navigation Semantics 

Like many WebApp design actions, navigation users begin with a series of user 
hierarchy and related use cases, developed for each category of user (actor). Each 
actor/user may use the WebApp differently and therefore have different navigation 
requirements. Moreover, the different use cases developed for each user/actor will 
define a set of classes that cover one or more content objects or WebApp functions. As 


each user/actor interacts with the WebApp, s/he encounters a series of navigation 
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semantic units (NSUs). An NSU is said to have a set of navigation elements called ways 


of navigating. 


3.7.2 Navigation syntax 

As design proceeds the next task is to define the syntax of navigation. Many options are 

available as you develop the syntax of each NSU. These are: 

e Individual navigation link: includes text-based links, buttons, icons, switches and 
graphical metaphors. You must choose navigation links that lead to high quality 
design. 

e Horizontal navigation bar: lists major content or functional categories in a bar that 
contains appropriate links. 

e Vertical navigation column: lists major content or functional categories or lists 
virtually all major content objects that can be expanded within the WebApp. 

e Tabs: represent a metaphor that is nothing more than the variation of a navigation 
bar or column. 

e Site maps: provide a table of contents for navigation to all content objects and 
functionality contained within the WebApp. 

In addition, icons and graphical links, audio and visual feedback, color of text-based 


navigation etc. are some of the design conventions that make navigation user friendly. 


3.8 Component-Level Design 

Modern WebApps provide sophisticated processing functions that 1) perform localized 
processing to generate content and navigation capability in dynamic ways, 2) provide 
computation and data processing capability that are appropriate for WebApp’s business 
domain, 3) provide sophisticated database query and access and 4) establish data 
interfaces with external business systems. To achieve these capabilities, you must 
design and program components that are identical in form to software components for 


traditional software. 
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3.9 Object-Oriented Hypermedia Design Method (OOHDM) 
One of the most widely discussed WebApp Design Methods is Object-Oriented 
Hypermedia Design Method (OOHDM). 


OOHDM is composed of four design activities: conceptual design, navigational design, 


abstract interface design and implementation. 


3.9.1 Conceptual Design 

OOHDM conceptual design creates a design for classes, subclasses, and relationships 
that define the application domain for the WebApp. UML can create appropriate class 
diagrams, aggregations and composite class representations and collaboration diagrams 


and other information that describes the application domain. 


3.9.2 Navigational Design for OOHDM 

Navigational design identifies a set of objects that are derived from the classes defined 
in conceptual design. A series of navigational classes or nodes are defined to 
encapsulate these objects. UML can be used to create appropriate use cases, state 
charts and sequence diagrams — all representations that help you in better 


understanding navigational requirements. 


3.9.3 Abstract Interface Design and Implementation 

A formal model of interface objects called an abstract data view (ADV) is used to 
represent the relationship between interface objects and navigation objects and 
interface objects (menus, buttons and icons) that assist in navigation and interaction. 
The OOHDM implementation activity represents a design iteration that is specific to the 


environment in which the WebApp will operate. 
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3.10 Object-Oriented Design Using UML 

Object-oriented design processes involve designing object classes and the relationships 
between these classes. These classes define the objects and their interactions in the 
system. When the system is realized as an executing program, the objects are created 


dynamically from these class definitions. 


Object-oriented systems are easier to develop than systems developed from functional 
approaches. Objects include data and operations to manipulate that data. They may be 
understood as stand-alone entities. Modifying the implementation of an object or 
adding services should not affect other objects. As objects are linked with things, there 
is often a mapping between real-world objects i.e., hardware objects and their 
controlling objects in the system. This helps to understand and maintain the system 
better. 


To develop a system design from a detailed, object-oriented design, the following 
things need to be done: 

1) Understand and define the context and external interactions with the system. 

2) Define the system architecture. 

3) Identify the main objects in the system. 

4) Develop design models. 

5) Specify design interfaces. 

As all creative activities are, design is not a clear-cut sequential process. You develop a 
system by getting ideas, proposing solutions and refining these solutions as information 
becomes available. You have to backtrack and retry as problems arise. The above 


activities are all interleaved and influence each other. 


3.10.1 System Context and Interactions 
The first stage in any software design process is to develop an understanding of the 


relationships between the software that is being designed and its external environment. 
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This is essential for deciding how to provide the required system functionality and how 

to structure the system to communicate with the environment. 

Setting the system boundaries helps you decide what features are there in the system 

being designed and what features are there in the associated systems. 

System context models and interaction models present complementary views of the 

relationships between a system and its environment. 

1. A system context model is a structural model that shows other systems in the 
environment of system being developed. 

2. An interaction model is a dynamic model that shows how the system interacts with 


the environment as it is used. 


3.11 Data Flow Design 

Data flow design is a method for carrying out the architectural large scale design of 
software. Data flow design depends on identifying the flows of data through the 
intended software, together with transformations on the flows of data. The method 
leads from a software specification to a large scale structure so that the software is 
expressed in terms of: 

1) Constituent components of software 


2) Interrelationships among software components 


We begin exploring data flow design using an analogy. Suppose a chef works in a 
kitchen all day preparing plates of Spaghetti Bolognese. The principal inputs to the 
system are: 

1) Spaghetti 

2) Meat 

The output from the system is: 

Plates of Spaghetti Bolognese 

As a matter of fact, data flows into the system, is transformed by actions (functions), 


and data flows out of the system. This diagram is called a data flow diagram. 
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Each line of data with an arrow on it represents a stream of data flowing through the 
system. In this example there are three: spaghetti, meat and plates of Spaghetti 
Bolognese. Each bubble consists of a transformation, activity or process for converting 


an input flow to an output flow. The following figure shows the steps that are involved. 


spaghetti 


prepare plates of 





food spaghetti 
bolognese 





Fig. 3.13: Data flow diagram for making Spaghetti Bolognese 


We end this section with a richer, more detailed diagram in which the components and 


their interrelationships are revealed. It is shown below: 


spaghetti 
———__+____—_»» 


boiled 
spaghetti 


~ 


plates of 
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spaghetti 


bolognese 





Fig. 3.14: More detailed data diagram for making Spaghetti Bolognese 
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In computer systems, bubbles correspond to software components. We have created a 
design for the kitchen system in terms of components and data flows between 


components. 


3.11.1 Identifying Data Flows 
We shall use a case study for the design of software to monitor a patient in a hospital. 


The specification as in Appendix A for the software is: 


A computer system monitors the vital signs of a patient in a hospital. Sensors attached 
to a patient send information continually to a computer: 

i) Heart rate 

ii) Blood pressure 


iii) Temperature 


If any of the vital signs crosses safe limits, the computer flashes a warning and an 
alarm sounds. The limits have default values. If any of the sensors fails, the computer 


flashes a warning and an alarm sounds. 
The data flow diagram of the major data flow for this software is shown below. It is 


simple to draw this diagram based on the specification for the software and by picking 


out functional steps that need to be carried out. 
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Fig. 3.15: Data Flow Diagram for Patient Monitoring Software 


This diagram also shows some data stores. These are shown as open boxes and 
represent files or databases. The difference between a data store and a data flow is 


that a data store is static. 


Drawing a data flow system for a proposed piece of software is a vital step in the 
method. For this, there are three alternative approaches: 


Method 1 is to start with a single bubble as in Fig. 3.16 that shows the overall function 


of the software and its input and output data flows. We then refine the bubble, or break 


it down into a smaller set of bubbles as in Fig. 3.17. 
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Fig.3.16: Initial Data Flow Diagram 
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Fig. 3.17: Refined Data Flow Diagram 


We continue redrawing bubbles as sets of smaller ones until we can’t do it anymore. 


In method 2 we start with the output data flow from the system and try to identify the 
final transformation that has to be done to it. Then we try to identify the transformation 


before that and so on until we have a complete diagram. 


Method 3 is the same as method 2, except that we start from the input data flow to the 


system and work out the sequence of transformations that should be applied to it. 


Therefore, we can obtain a data flow diagram using one of the three methods. We can 
now consider each bubble to be a component that inputs a serial stream of data from 


one component and outputs a serial stream to another. Some operating systems (such 
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as Unix) and some languages (such as piped input and output streams facility in Java) 
support this filter and pipe software architecture. This means we can directly implement 
a data flow diagram as a series of pipes and filters. However, if pipes are not available, 
a data flow diagram must be transformed into a structure in which components make 


method calls on each other. 


3.11.2 Creation of a Structure Chart 

The first and most crucial step of a data flow design is a data flow diagram. Such a 
diagram shows the transformations and the data flows between them. The next step is 
to convert the data flow diagram into a structure chart or structure diagram. A structure 
chart shows the components that comprise software and how they call each other. 
Suppose for example, some structure chart consists of three components A, B and C. 
Suppose component A calls both the components B and C. The structure chart for these 


components is shown below. 





Fig. 3.18: Structure chart in which component A 


calls components B and C. 
A structure chart is, therefore, a hierarchical diagram that shows components at higher 


levels calling components at lower levels. A structure chart is a tree with one single root 


at the top of the chart. Notice, however, that a data flow diagram is not hierarchical. 
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Let us now consider the patient monitoring system and see how to convert the data 
flow diagram into its equivalent structure chart or structure diagram. In this diagram, 
the central and most important bubble is the check bubble. Suppose that the bubbles 
are connected by pieces of strings. Grasp the central component and lift it into the air 
and let the others dangle beneath. Next change the bubble shapes into rectangles. As a 


result, we get the figure as in Fig. 3.19. 


The check component calls the convert component which in turn calls the read data 
component to obtain data. Then it calls the display message component to display 


the output on the screen. 


As we have illustrated, the steps for converting a data flow diagram into a structure 

chart are: 

1) identify the most important bubble (transformation). 

2) convert this component into the topmost level component in the structure chart. 

3) Allow the other components to dangle beneath the topmost level component, 
creating a hierarchical tree. 

4) Convert the bubbles into rectangles and data flows into lines representing method 


Calls. 


Summing up, the data flow design is a method for high level or architectural design. 
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Fig. 3.19: Structure Chart for Patient Monitoring 
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CHAPTER4 


Software Processes 
4.1 Waterfall Model 


The waterfall model is an established approach to software development and is widely 
used. 


4.1.1 Principles of the model 

In the waterfall method, the steps are sequential. Each stage is completed until 
conclusion before the next stage begins. Additionally, each stage produces a product 
until it is input into the next stage. For example, all coding is completed before testing 
begins. 


Requirements 
Engineering 


Architectural 
design 


Detailed 
design 


Coding y 


Unit 


testing ) 


System 


testing ) 


Acceptance 





Fig. 4.1: Waterfall method 
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The principles of the waterfall method: 

1) It is a series of steps. 

2) Each step is well defined. 

3) Each step creates a definite product. 

4) Each product forms the basis for the next step. 


5) Each step can be verified or validated. 
The complete waterfall process method is like a series of small waterfalls because each 
stage produces a product before it can flow like water to the next stage. As water 


cannot flow up but can only flow down, once a step is executed, there is no going back. 


The inputs and outputs for each step of waterfall process are shown in tabular form 
below: 


Table 4.1: Waterfall Process Steps 


Stage 


requirements engineering 
architectural design 
detailed design 

coding 

unit testing 

system testing 


acceptance 


Input 


none 

requirements specification 
architectural design 
module specifications 
coding 

tested modules 


tesied system 


4.1.2 Modified Waterfall Method 


Output 


requirements specification 
architectural design 
module specifications 
coding 

tested modules 

tested system 


Satisfied client 


An error uncovered at one stage cannot be solved by going backwards in the waterfall 
process model described above. So a variation of the process model is to provide 
feedback to the previous stage so that errors found in a stage can be corrected by 


going back to the immediate previous stage. 
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Fig. 4.2: Modified Waterfall Method 


4.2 The Spiral Model 
This model is based on the recognition that it involves enormous uncertainty at many 
stages and therefore, the involvement of risk assessments. These assessments are 


followed by deciding alternative actions, selecting the best action and re-planning. 
The model spirals out from near the center of the process and passes through four 


phases. These are: 1) analyze risks and plan 2) analyze requirements 3) construct 4) 


analyze. These phases convey the increasing expenditure of time, effort and progress. 
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As we mentioned, the spiral model involves the idea of risk. There are uncertainties 
associated with software development and should be dealt with as carefully as possible. 
Some of the risks that could be experienced are: 

1) The client changes some of his requirements. 

2) During a time-consuming development, user’s requirements are ignored. 

3) Someone quits the development team. 

4) One of the component tasks of the development goes beyond its deadline. 

5) The software performance is slow. 

6) The software occupies too much main memory. 

7) A target hardware configuration changes. 

8) A bug is difficult to get rid of. 


The spiral model makes provision for areas concerning the above uncertainties and 


therefore, minimizes the risk to the software project. 


Each of the four phases of the spiral model can be further described as follows: 


Stage 1: Risk Analysis and Planning 

1) Meeting the objectives of the product of this stage — performance, functionality, 
ease of change. 

2) Identifying the conditions that affect this stage — cost, deadlines, interfaces with 
other software components 

3) Identifying risks 

4) Identifying the alternative ways of implementing the stage — buying it, reusing 
something else, implementing it one way or the other. 

5) Evaluating the alternative implementation schemes against the criteria set by the 
objectives and conditions. 

6) Finding ways to overcome the risk. 


7) Establishing the deadline for the next project phase. 
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Stage 2: Analysis of Requirements 


This takes into account meeting the requirements for the next stage. 


Stage 3: Construction 
At this stage, the development of a product may be implemented. This stage may 
involve design, implementation, validation and verification. A product at this stage may 


be a specification, architectural design, prototype or software component. 


Stage 4: Evaluation 
Finally an evaluation is carried out to find out if the project is on track and if the entire 
development team and client(s) are happy. If yes, the project can head on to the next 


cycle. 


Construct Evaluate 





Analyze 
requirements 


Analyze risks 
and plan 





Fig. 4.3 : The Spiral Model 
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4.3 Prototyping 

A prototype is an initial design of the software system which is tried out to test 
concepts, design, find out more about the problem and figure out solutions. Rapid 
iterative development of the prototype is essential so that costs are minimum and 


stakeholders can experiment with the prototype in the early software process. 


A software prototype can be used in a software development process to help monitor 


changes that may be needed. 


1) In the requirements engineering process, a prototype can help with the elicitation 
and validation of system requirements. 
2) In the system design process, a prototype can help with the discovery of software 


solutions and initiation of user interface design. 


The system prototypes allow users to see how well the system supports their work. 
They may get new ideas for requirements and find strengths and weaknesses in the 
software. As the prototype is developed, it may reveal errors or omissions in the 


proposed requirements. This may lead to modification of the system specification. 


While a system is designed, a system prototype may be used to test the feasibility of 
the proposed design. For instance, a database design may be prototyped to test if the 
system supports the volume of data required for the most common queries. As another 
instance, rapid prototyping with end user involvement is the best way to develop user 


interface design for software systems. 


To reduce prototyping costs it may be wise to leave out some functionality of the 
prototype. For instance, you may decide to relax non-functional requirements such as 


response times and memory utilization. 


The final stage of prototyping is prototype evaluation. This means to make provision for 
user training until they are comfortable with the new system and working on it routinely 


to discover requirements errors and omissions. 
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A process model for prototype development is shown below: 


Establish Define 
Prototype Prototype 
Objectives Functionality 


Develop Evaluate 
Prototype Prototype 


Prototyping Outline Executable Evaluation 
Plan Definition Prototype Report 


Fig. 4.4: The Prototyping Model 





4.4 Incremental Development 

This process model is based on the development of an initial implementation, subjecting 
it to user comment and going through several versions until an adequate system is 
developed. Specification, development and validation are interleaved with rapid 
feedback from these activities. 


Each increment or version of the system involves some of the functionality that is 
needed by the customer. The early increments include the most urgent or important 
functionality. This means that the customer can evaluate the system at an early stage 
in the development in order to find out if it delivers what is required. If not, only the 
current increment is to be modified and possibly new functionality for future 


increments. 


The problems of incremental development become acute for large systems, with 
different teams working on different parts of the system. This has, therefore, to be 


planned in advance rather than developed incrementally. 
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Fig. 4.5: Incremental Development Model 





4.5 Open Source Software Development 

Open source is a development approach in which the source code is completely free to 
access. The term “open source” applies to both the product and the development 
approach. Any individual is able to view it, modify it or duplicate it. 


Some examples of larger open source products are Mozilla web browser, Apache web 
browser, GNU/Linux and GNU/HURD operating systems, MySQL database software, Perl 
programming language and My Office and Open Office suites. 


4.5.1 Principles of Open Source Development 


Open source development is an extension of Hacker Community’s attitude to the 
development of software. Hackers are now regarded as a community of highly skilled 
programmers who relish writing code and enhance their reputation of writing code. 
Because knowledge and information are freely shared without restriction, it initiates 


group thinking and superior ideas on the overall. 
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Similarly, in open source development, the code is not confined to a small group of 
developers but shared by a bigger audience, which leads to more reliable code via 


greater thinking, ideas and rectification. 


Because of the openness of the program code, the community has imposed its own 
license agreement for use on open source products. The GNU general public license 


(GPL) is a software license which protects its openness. 


However, the openness and sharing of code does not mean the open source products 
are always free to buy. Companies often sell their software as a complete package 


including user manuals and additional help services. 
4.5.2 The Techniques of Open Source Development 


There exists a split within open source development between ethics and philosophy. 


Nevertheless, the development strategies remain the same between the two. 


The process is initiated by a single developer with requests for collaboration to the 
hacker community. The Internet often provides the bridge between the developers and 


distribution of source code via web, file transfer sites and email. 


The head developer specifies most user requirements. Additional user requirements are 
worked out by developers themselves modifying the source code or through a 
communal process called code forking. Code forking occurs when the developer has 
conflicting ideas on a user requirement. The code is split giving arise to two copies from 
the base code. As the code is split this way, two different products are developed in 


parallel. The more significant or reliable one is retained and survives. 


The design of the code is implemented by web-based tools. UML diagrams or cross 
reference displays using hyperlinks are used for deployment of the design. However, 


the design documentation lacks for open source products. 
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An explicit project manager or management group decides on the usefulness or 
appropriateness of contributions made by the wider development community. They 


usually add the patch to code and play the role of chief implementer of the code. 


Once contributions have been made, beta versions of open source products are 
released. Releases are made frequently so that contributions for appropriateness can be 
tested quickly. Feedback on the latest contribution is given and the contributions cycle 


on the code continues until the community is satisfied with the eventual outcome. 


Development communities and product websites are sources of support for users of 
open source products. The websites contain installation tutorials and user forum groups 


providing technical support. 


As an alternative means of support, commercially supported versions of open source 


software are available for purchase along with supporting manuals and services. 


4.6 Agile Methods and Extreme Programming 

Agile methods are incremental development methods in which the increments are small 
and new releases of the system are created and available every two-three weeks. They 
involve customers in the development process to get rapid feedback on changing 
requirements. They minimize documentation by using informal communication rather 


than formal meetings with documentation. 
4.6.1 What led to Agile Methods? 


In the 1980s and early 1990's, software engineering methods were heavy-weight, plan- 
driven approaches for developing large and long-lived software systems such as 


aerospace and government systems. 


When these approaches are applied to small and medium-sized business systems, the 
overhead is so large that it dominates the software development process. More time is 


spent on how the system should be developed than on program testing and 
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development. As the system requirements change, the specification and design has to 


change with the program. 


Dissatisfaction with these heavyweight approaches led many developers in the 1990's 
to propose new “agile methods”. These allowed the development team to focus more 
on the software rather than on its design and documentation. Agile methods 
universally rely on an incremental approach to software specification, development and 
delivery. They are best suited to application development where the system 


requirements change rapidly during the development process. 


The philosophy behind agile methods is reflected in the agile manifesto that was agreed 
on by many of the leading developers of these methods. This manifesto puts emphasis 


on: 


e Individuals and interactions over processes and tools 
e Working software over comprehensive documentation 
e Customer collaboration over contract negotiation 


e Responding to change over following a plan 


Table 4.2: Principles of Agile Development 


Customer involvement Customers should be closely involved throughout the development process. 
Their role is provide and prioritize new system requirements and to evaluate 
the iterations of the system. 


Incremental delivery The software is developed in increments with the customer specifying the 
requirements to be included in each increment. 


People not process The skills of the development team should be recognized and exploited. Team 
members should be left to develop their own ways of working without 
prescriptive processes. 


Embrace change Expect the system requirements to change and so design the system to 
accommodate these changes. 


Maintain simplicity Focus on simplicity in both the software being developed and in the 
development process. Wherever possible, actively work to eliminate complexity 
from the system. 
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4.6.2 Plan-driven and Agile Development 


Agile approaches to software development consider design and implementation to be 
the central activities in the software process. They incorporate other activities such as 
requirements analysis and testing into design and implementation. On the contrary, a 
plan-driven approach to software development includes separate stages in the software 
process with outputs associated with each stage. The outputs from one stage are used 


as a basis for planning for the following process activity. 


In a plan-driven approach, iteration occurs within activities with formal activities for 
communicating between stages of the process. For example, requirements will arise 
and eventually a requirements specification will be produced. This then serves as an 
input to the design and implementation process. In an agile approach, iterations occur 
across activities and the requirements and the design are developed together rather 
than separately. 
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Fig. 4.6: Plan-driven and Agile Developments 
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Most software projects include practices from plan-driven and agile approaches. To 
decide on a balance between the plan-driven and the agile approaches, a range of 


questions need to be asked, some of which are given below: 


1) Is it important to have a detailed specification and design before moving on to 
implementation? If yes, a plan-driven approach may be the solution. 

2) Does an incremental delivery strategy, where you deliver the software to the 
customers and get rapid feedback from them seem feasible? If yes, go for an agile 
approach. 

3) How large is the system that is being developed? Agile methods are best applied to 
small or medium-sized software systems where a small co-located team is assigned to 
work informal communications. Plan-driven methods are best applied to large system 
where large development teams are assigned. 

4) What type of system is being developed? Systems requiring a lot of analysis before 
implementation would need a fairly detailed design to carry out this analysis. In that 
case, a plan-driven approach would be appropriate. 

5) What is the expected system lifetime? Long-lifetime systems may require more 
design documentation to communicate the original intentions of the system developers 
to the support team. However, supporters of agile methods are right in arguing that for 
such systems, there is no need to keep documentation up-to-date nor will it be valid for 
long-term system maintenance. 

6) What technologies are available to support system development? Agile methods 
rely on good tools for an evolving design. If the system uses an IDE that does not have 
good tools for analysis and visualization, then a more detailed design specification 
would be required and hence the need for a plan-driven approach. 

7) How is the development team organized? If the development team is distributed or 
part of the team is being outsourced, then detailed design documents need to be 
distributed across the teams. These documents may need to be planned in advance and 


hence the need for plan-driven approach. 
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8) Are there cultural issues that may affect the system development? Traditional 
software engineering organization has the culture of plan-driven approach. This 
requires detailed design specification rather than informal knowledge in agile 
approaches. 

9) How good are the designers and programmers in the development team? It is 
argued that agile approaches require higher skill levels than plan driven approaches 
where the design is simply translated into code. If the team consists of people with low 
level skills, among them the better ones should design while the others should code. 
10) Is the system subjected to external regulations? Some software systems require an 
external regulator such as, Federal Aviation Authority (FAA) which requires to approve 
the software system of an aircraft. In those cases, detailed documentation would be 


required as part of the safety measures. 
4.6.3 Extreme Programming (XP) 


Extreme programming (XP) is probably the best known and widely used among agile 
methods. In XP, several new versions of a system may be developed, integrated and 


tested within a single day. 
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Fig. 4.7: Extreme Programming Process 
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In extreme programming, requirements are expressed as scenarios or user stories 
which are directly implemented as a series of tasks. Programmers work in pairs and 
develop tests for each task before writing the code. All code should run successfully and 


integrated into the system. There are short time gaps between releases of the system. 


Extreme programming involves a number of practices, which are typical of agile 


approaches: 


1) Incremental development is supported through small frequent releases of the 
system. Requirements are based on customer stories or scenarios, which form the 
basis for deciding what functionality should be included in an increment. 

2 


aS 


The customer is continuously engaged with the development team and the customer 
representative collaborates with the development team and is responsible for 
defining acceptance tests for the system. 

3 


aS 


People not process are involved in pair programming, get ownership of system code 

and do not have to work for long hours during the development process. 

4) Change is embraced through regular system releases to customers, test-first 
development and refactoring (meaning improving the structure and organization of 
a program, which is also an important mechanism that supports change tolerance) 
to prevent code degeneration and integration of new functionality. 

5 


aS 


Maintaining simplicity is done through refactoring to improve code quality and by 


using simple designs that show no signs of future changes to the system. 


In an XP process, customers are involved in specifying and prioritizing system 
requirements. The requirements are not listed as required system functionality. Rather 
the system customer is part of the development team and discusses scenarios with 
other team members. Together they develop a story card that encapsulates customer 
needs. The development team then includes a scenario in the next release of the 


software. 
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The story cards are the main inputs to the XP planning process. Once the story cards 
have been developed, developers break down these as tasks and figure out what effort 
and resources are required to implement each task. This usually involves the customer 
in discussion with the team to refine requirements. The customer than prioritizes these 
requirements and chooses those scenarios that will immediately deliver good business 


support in about two weeks when the next release of the software would be available. 


As requirements change, the unimplemented stories change or may be discarded. If 
changes are required to a system that has already been delivered, new story cards are 
developed and again the customer decides whether these changes should have priority 


over new functionality. 


Table 4.3: Extreme Programming Practice 


Incremental planning Requirements are recorded on Story Cards and the Stories to be included in a 
release are determined by the time available and their relative priority. The 
developers break these Stories into development Tasks’. 


The minimal useful set of functionality that provides business value is developed 
first. Releases of the system are frequent and incrementally add functionality to 
the first release. 


Simple desi Enough design is carried out to meet the current requirements and no more. 
gn 8 8 


Test-first development An automated unit test framework is used to write tests for a new piece of 
functionality before that functionality itself is implemented. 


Refactoring All developers are expected to refactor the code continuously as soon as possible 
code improvements are found. This keeps the code simple and maintainable. 


Pair programming Developers work in pairs, checking each other's work and providing the support 
to always do a good job. 


Collective ownership The pairs of developers work on all areas of the system, so that no islands of 
expertise develop and all the developers take responsibility for all of the code. 
Anyone can change anything. 


Continuous integration As soon as the work on a task is complete, it is integrated into the whole system. 
After any such integration, all the unit tests in the system must pass. 


Sustainable pace Large amounts of overtime are not considered acceptable as the net effect is 
often to reduce code quality and medium term productivity 


On-site customer A representative of the end-user of the system (the Customer) should be 
available full time for the use of the XP team. In an extreme programming 
process, the customer is a member of the development team and is responsible 
for bringing system requirements to the team for implementation. 





During the planning game, there may arise questions, and solutions need to be 
explored. The team may carry out prototyping or trial development to deal with a 
problem and come to a solution. In XP terms, this is a spike, which is an increment 
where no programming is done. These spikes may also be used to design system 


architecture or develop system documentation. 


Extreme programming takes the extreme approach to incremental development. New 
versions of the software may be built several times during the day and releases 
delivered to customers every two weeks. Release deadlines are never missed. However, 
if there are development problems, the customer is consulted and functionality removed 


from the planned release. 


When a programmer builds the system to create a new version, he or she must run all 
existing tests of the system and also those for new functionalities. This only occurs if all 


tests run successfully. This then becomes the basis of the next iteration. 


According to traditional software engineering, you should anticipate future changes and 
design for it so that these changes can be easily implemented. Extreme Programming 
has, however disregarded designing for change because it is often wasted effort. The 
changes anticipated often never materialize and often different change requests are 
made over time. Therefore, the XP approach accepts that changes will happen and 


reorganizes the software when these changes occur. 


A problem with the incremental approach is that it degrades the software structure so 
that changes to the software becomes harder and harder to implement. Extreme 
programming tackles this problem by suggesting that the software be constantly 
refactored. This means that the programming team looks for improvements to the 
software and implements them immediately. When a team member sees code that can 
be improved, he makes those improvements even when there is no immediate need for 
them. Examples of refactoring include the reorganization of a class hierarchy to remove 
duplicate code, the tidying up and renaming of attributes and methods and the 


replacement of code with calls to a method embedded within a program library. 
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In theory then, software is always easy to understand and change. But in practice, this 
may not always be the case. Sometimes refactoring is delayed because time is devoted 
to the implementation of new functionality. In many cases, new features and changes 
cannot be implemented by code-level refactoring but require the system architecture to 


be modified. 


In practice, all of the companies who have adopted the XP approach do not use all of 
the practices shown in Table 4.3. They pick and choose according to their convenience. 
For example, some companies find pair programming useful while others adopt 
individual programming and reviews. Some companies don’t do refactoring on parts 
they didn’t develop and use conventional requirements rather than user stories. 
However, most companies who have adopted an XP variant use small releases, test-first 


development and continuous integration. 
4.6.4 Testing in XP 


Some approaches to incremental development have a very informal testing method 
compared to plan-driven approaches. Formal testing cannot be carried out in the 


incremental approach because there is no actual requirements specification to follow. 


XP introduces an approach to testing that reduces the entry of undiscovered errors into 


the current version of the system. 
The key features of testing in XP are as follows: 


1) Test-first development 
2) Incremental test development from scenarios. 
3) User involvement in the test development and validation 


4) Incremental automated testing frameworks 


In test-first development, you write the test first instead of writing the code so that the 


test can be carried out while developing the code and errors can be discovered. 
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This approach helps to make clear the link between a system requirement and the code 
implementing that requirement. In XP this link is always obvious because the story 
cards representing the requirements are transformed into tasks and the tasks are the 


unit of implementation. 


In test-first development, task implementers have to thoroughly understand the 
specification before they can write tests for the system. For this to happen omissions 
and ambiguities in the specification will have to be clarified before tests can be written. 
This also avoids the problem of test-lag. This happens when code developers are 
advancing at a faster pace than test implementers so that tests are skipped to maintain 


code development. 


The development team expresses requirements as user stories or scenarios and the 
user prioritizes these for development. The development team assesses these scenarios 
and breaks them down into tasks. Each task generates one or more unit tests, which 


check the implementation within those task(s). 


The role of the customer in the testing process is to help develop acceptance tests for 
the stories that are to be implemented in the next release of the system. Acceptance 
testing is the process where the system is tested using customer data to meet 


customer’s needs. 


In XP, acceptance testing like development is incremental. The customer who is part of 
the development team writes tests as development proceeds. People who lead the 
customer role may have very limited available time and may not be willing to work full- 
time with the development team. The customer may think that the requirements were 


enough of a contribution and may be unwilling to get involved in the testing process. 


Test automation is essential for test-first development. Tests are written as executable 
components before the task is implemented. An automated testing framework is a 
system that makes it easy to write executable tests and submit a set of tests for 


execution. These tests can be run quickly and easily. Whenever any functionality is 
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added to the system, any problems that the new code generates are detected 


immediately. 


Test-first development and automated testing usually results in a large number of tests 
to be written and executed. The incremental approach, however, doesn’t ensure 


thorough testing. This is because: 


1) Programmers do not always write complete tests and take short-cuts so that the 
tests may not cover all exceptions. 

2) Some tests may be very difficult to write incrementally. For example, for complex 
interface systems, it is often difficult to write unit tests for code implementing 
display logic and workflow between screens. 

3) It is difficult to judge that tests are complete. Crucial parts of the system may not be 


executed and so remain untested. 


If the tests are not reviewed and further tests written after development, undetected 


bugs may be delivered in the system release. 
4.6.5 Pair Programming 


Another innovative practice is incorporated in XP which is pair programming where 
programmers work in pairs to develop the software. They actually sit at the same 
workstation to develop the software. However, the same pairs may not program 
together. Pairs are rather created dynamically so that all members of the development 


team work together. 
The use of pair programming has a number of advantages: 


1) It supports the idea of collective ownership and responsibility for the software 
system. Rather than individuals, the team is responsible for solving problems with 
coding. 

2) It acts as an internal review process because the same lines of code are observed at 


least by two people. Code inspections and reviews are highly successful in detecting 
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problems and bugs in the system earlier on. However, they are time consuming to 
organize and may introduce delay into the development process. But on the other 
hand, pair programming is an informal review process which doesn’t detect errors as 
much as the formal program inspection but it’s cheaper in the long run than the 
latter. 

3) It helps support refactoring, which is a process of software improvement. The 
difficulty in incorporating refactoring in normal development process is that an 
individual becomes inefficient in refactoring compared to somebody developing code 
because the former is meant for long term benefits. But while pair programming and 
collective ownership are utilized, others can take up refactoring supporting the 


process. 


4.7 The Unified Process 
The Unified Process consists of all the best features and characteristics of all traditional 
software process models but especially draws on the principles of agile software 


development. 


The Unified process pays especial significance to customer communication and 
streamlined methods for a customer’s system view, the use case. It emphasizes the 
vital role of software architecture and helps the architect focus on the right goals such 
as comprehensibility, reliance on future changes and reuse. It suggests a process flow 
that is incremental and iterative, which is essential in modern software process 


development. 
4.7.1 What led to the Unified Process? 


During the early 1990's scientists were working on a unified method that would 
combine each of the best features of their object-oriented design analysis and design 
methods and integrate methods adopted by other experts in object-oriented modeling. 
The result was UML- unified modeling language, a robust notation for modeling and 
developing object-oriented systems. By 1997, UML became, in fact, the industry 


standard for object-oriented software development. 
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4.7.2 Phases of the Unified process (UP) 


The following figure shows the phases of the Unified Process (UP): 
Flaboration 


Inception 
| ne, 


Release ~~ Transition 


software increment 
\ 


Production 





Fig. 4.8: Phases of the Unified Process 


The inception phase of the UP consists of both the customer communication and 
planning activities. By collaborating with the stakeholders, business requirements of the 
software are identified. A rough architecture for the system is proposed and the 
incremental and iterative nature of the ongoing project is developed. Fundamental 
business requirements are described through use cases that describe functions and 
features that each major class of users desires. The architecture will be refined into a 
set of models that will represent different views of the system. Planning identifies the 
resources, assesses the major risks, defines the schedule and establishes the phases as 
the software increment is developed. 


The elaboration phase consists of planning and modeling activities for the generic 
process model. This phase refines and expands the preliminary use cases of the 


inception phase and expands the architectural representation to include five different 
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views of the software: the use case model, the requirements model, the design model, 
the implementation model and the deployment model. The plan is carefully reviewed 
during the elaboration phase to ensure the scope, risks and delivery dates remain 


reasonable. 


Using the architectural model as input, the construction phase develops the software 
components that will make each use case functional for end users. To ensure this, the 
requirements and design models that were initiated in the elaboration phase are 
completed to reflect the final version of the software increment. As components are 
implemented, unit tests are designed and executed, component assembly and 
acceptance testing are conducted, and use cases derive a suite of acceptance tests that 


are executed prior to the next UP phase. 


The transition phase consists of the latter stages of construction activity and initial 
stages of deployment activity such as feedback and report. The software is given to end 
users for beta testing and their feedback reports both defects and changes to be made. 
During this phase, also the software team prepares the required support information 
such as, user manuals, troubleshooting guides and installation procedures required for 
the software release. At the end of the transition phase, the software increment 


becomes a usable software release. 


The production phase coincides with deployment activity of the generic process. During 
this phase, the ongoing phase of the software is monitored, support for operating 
infrastructure is provided and defect reports and requests for changes are submitted 


and evaluated. 


It is possible that at the time elaboration, construction and transition phases are being 
executed, work on the next software increment may already be initiated. For this 
reason the five phases of UP are not exactly sequential but work together with stalling 


concurrency. 
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CHAPTERS 


The Project Teams 


5.1 Teams 
This section explains the principles behind team working, how functional and project 


teams operate and finally how the chief programmer team operates. 
5.1.1 Introduction 


Software developers rarely work alone. Rather, they share an office working on 
different projects and collaborating on larger projects. In the section on “Teams”, we 
begin by analyzing some of the problems of group work and later explain the 
techniques for the software team organization: the functional teams, project teams, 


chief programmer teams and object oriented teams. 
5.1.2 The Principles of Teams 
Team activities are concerned with: 


1) The communication among people in the team 
2) Who does what 


The above two activities are now discussed. 
The Communication Problem 


When two or more people work on a piece of software, they definitely need to 
cooperate and collaborate. They have to communicate component specifications — 
component names, component functions, parameter types and so on. Often interfaces 
are complex, involving detailed file layouts. Also there are queries because of the 


difficulty of specifying the interfaces accurately. 


During the lifetime of a project, a team member leaves, or becomes ill or goes on 


holiday. Another team member has to sort out the project in their absence. When new 
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people join the team, they have to be helped to understand what the software is for, 
what has been done and why the structure is as it is. They take up the time of those 
who remain while the new team members have to further familiarize themselves with 
the standards and procedures being used in the project or even learn a new 


programming language. 


Therefore, aS more and more people are added to a team, the time taken for 
prospective communication may never be attained and so they completely hamper the 


project. 
The Division of Labor 


The second major issue in team organization is deciding how to break down a large 
task among team members. Designers carry out a variety of tasks for instance, 
designing is very challenging while tasks for instance, keying corrections or filing listings 
are less demanding. One approach of dividing the software development task among a 
group of people is to expect that each person does a mix of tasks. Another approach to 
divide up the task such that the person skilled in designing gets the whole design task 


while another person skilled in keying corrections gets that task. 
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Fig. 5.1: Skill Requirements at Each Stage of a Project 
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5.1.3 The Functional Team 


In the functional team organization all the members of the team carry out the same 
type of work so that there is a team of programmers, a team of analysts, a team of 
testers and so on. At any one time, members of a team are working on different 


projects. The work of a project is carried out by the people from different teams. 


A major problem of functional teams is that people who are working together on a 
single project are not a cohesive team. They may even be separated working in 


different offices. Close and easy communication is not possible. 


Another problem of functional teams is that the person responsible for a project is not 
the manager or leader of the people working on his or her project. Therefore, s/ he 


may not have as much control over them as they would like. 
5.1.4 The Project Team 


In a project team, everyone is involved in developing at the same time. The team 
usually consists of people who carry out all of the development work for instance, 
requirements analysis, programming, testing etc. Initially this kind of team consists of 
only one person. As requirements engineering gets carried out, the team grows to two 
or three until it reaches its full bloom during coding and testing. Towards the end of the 
project, members leave the team until finally the project is completed and the team 
abandons. The project manager is usually the member of the team and in control of the 


team. 


The drawback of the project team is that it grows stronger and weaker according to the 
demands of the project. Initially one or two people work on analysis and architectural 
design. During implementation the numbers reach the maximum. Towards the end, 


when the system is being put into operation, the numbers minimize. 
5.1.5 The Chief Programmer Team 
The principles behind chief programmer team organization are to: 
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1) divide the work among skilled specialists 
2) structure the team in a well-defined way so that each individual’s work is clear and 


minimum communication occurs. 


In the chief programmer team, each member is a highly trained specialist. In this team, 
the job titles are chief programmer, backup programmer, librarian and other specialist 


programmers as and when necessary. 
The roles of these team members are as follows: 
Chief Programmer 


A chief programmer is a highly skilled software engineer who develops the crucial parts 
of the system. He is actually the designer of the software who specifies all the 
architectural components of the software. He not only specifies these components but 


also supervises the integration and testing of the whole system. 
Backup Programmer 


A backup programmer’s skill is comparable to the chief programmer. His job is to help 
the chief programmer with his tasks and act as the chief programmer when he is absent 
for any reason. In case the chief programmer leaves the team, the backup programmer 


can easily take over. 
Librarian 


A librarian is someone who maintains and manages the documentation associated with 


the system. S/he usually has some training with a computer system. 
Other Specialist Programmers 


As and when necessary, other specialist programmers are brought into the team to 
work on subsystems as specified by the chief programmer. Each of these programmers 
are specialized in a particular software area such as, databases, interfacing and 


graphics. 
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Thus, the benefits of the chief programmer team to the organization are: 


1) much better programmer productivity because 
e less time is spent on communication 
e each programmer is executing highly specialized work in which they are highly 
skilled 
2) improved software quality because 
e the team is organized around highly skilled programmers 
e the interfaces between software components are obvious 
e fewer bugs arise from communication problems because there are fewer 
programmers 
3) meeting deadlines successfully because 
e the project is more visible and clearly understood through the high technical 


involvement of the chief programmer. 


Note: Anyone who is a good programmer but does not want to go into management 


can become a chief programmer. 
5.1.6 The Object-Oriented Team 
Object-oriented development tries to achieve two objectives: 


1) reuse of existing components from the standard library or in-house (within the 
organization) library 


2) creation of new, reusable components for the in-house library 


Thus, organizations oriented towards the object-oriented paradigm divide their 
personnel into application programmers on one hand, and class or component 


developers on the other. 


The benefits of an object-oriented paradigm can only be realized with the combined 
efforts of identifying reusable software components and organizing such components 


within an accessible library. A domain-specific class library becomes a valuable asset of 
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the organization. This is because research has shown that large organizations are able 
to reduce the amount of new code on their large projects by a factor of 50% through 


the use of such libraries. 


As a result, application programmers can be thought of consumers; they develop 
application-specific classes but always seek to reuse existing library components. They 
also have a responsibility to identify useful abstractions that can be migrated from the 


applications to the library. 


Class programmers (or component developers) are thought of as producers; they 
produce reusable components of general use to the organization. Their job is to polish, 
generalize, reorganize and enhance library classes. In fact, producing reusable 


components is more difficult than writing components for a specific project. 
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CHAPTER6 


Software Metrics and Quality Assurance 


6.1 Introduction 
Quality assurance has become particularly important because of the increasing reliance 


of business on software. Software is of good quality if it at least: 


1) meets user needs 
2) is reliable (i.e., does not fail) 


3) is easy to maintain (i.e., to correct or change) 


An important aspect of quality is measurement. In software engineering, measures are 
termed as metrics. A metric is a measure such as, cost or size, that can be applied to 
software. Metrics can be applied throughout the software development process. Metrics 


address issues as: 


1) how big the software will be 

2) how complex the component is 
3) how reliable the software is 

4) how much the software will cost 


5) how much effort the software will need to meet changed needs 


Metrics are applied in various ways to software. The purposes of metrics in software 


engineering include: 


1) predicting qualities of developing software 
2) making judgment on the quality of a piece of developing software 
3) monitoring and improving the software development process 


4) comparing and assessing different software development approaches 


In this chapter, we first discuss metrics and then the application of quality assurance to 


software. 
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6.2 Basic Metrics 

The simplest measure of software is its size. Two basic metrics are the size in bytes and 
size in the number of statements. The size in statements is termed as LOCs (lines of 
codes) or SLOCs (source lines of codes). The size in bytes is dependent on the main 
memory and disk space requirements and affects performance. The size in statements 
relates to development effort and maintenance costs. A longer program may not take a 
longer time to develop than a shorter program because what really matters is the 


complexity of software. 


The second major technique is person months, a measure of developer effort. Since 
people’s time is a major factor in software development, person months usually 
determine cost. If an organization measures the development time for components, the 
information can be used to determine the time of future developments. It can also be 


used to verify the effectiveness of new techniques used. 


The third basic metric is the number of bugs. As a component is being developed, a log 
can be kept of the bugs that are found. This helps predict how many bugs will remain 
at the end of the development. These figures also help to determine how good the new 


techniques are. 


6.3 Complexity Metrics 

In the early days of programming, main memory was small and processors slow. The 
effort was more on making programs efficient. Nowadays the pressure is on reducing 
the development time of programs and easing the burden of maintenance. Therefore, it 
becomes necessary to write clear and simple programs so that checking, understanding 


and editing can be carried out conveniently. 
What accounts for simplicity? 


1) It is quicker to debug simple software 
2) It is quicker to test simple software 


3) Simple software is likely to be reliable 


93 


4) It is quicker to modify simple software 


In the world of design engineering, a good designer maintains a complete 
understanding and control over every aspect of their project. The more difficult a 
project, the more they insist on simplicity because without it no one can gain full 


understanding. 


Many software engineers and programmers strive to make their software as clear and 
simple as possible. When a programmer finishes a program, he is satisfied that it both 


works correctly and is clearly written. 


What are actually the factors that affect program complexity? The program length, the 
number of alternative paths through the program, and the number of references to the 


data are all measures of complexity. 


Among many attempts to measure software’s complexity is Mc Cabe’s cyclomatic 
complexity. This complexity shows that it does not depend on the number of 
statements in the program but rather the decision structure of the program for 
instance, if, while and other similar conditions. To measure the cyclomatic complexity 
of the program, we have to count the number of conditions and add one. Consider the 


following program segment: 





Fig. 6.1: A Program Segment 


This program segment has a cyclomatic complexity of 2 because it has one if condition 


and we add 1 to it give the complexity of 2. 


Note that if a program has only a sequence of statements, it has a cyclomatic 


complexity of 1, however long it is. So the smallest value of this metric is 1. 
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A valid complexity measure can help software developers to a great extent in the 


following ways: 


e in estimating the effort needed in maintaining a component. 
e in selecting the simplest design from among several possibilities. 
e in signaling when a component is too complex and so in need of restructuring or 


subdivision. 


6.4 Faults and Reliability (Estimating Bugs) 

A human error in developing software causes a fault (or bug) resulting in a failure of 
the system (or several different failures). Testing every single piece of software gives 
rise to faults. If software developers develop software and they are able to tell clients 
professionally and honestly how many errors or estimated bugs there are, the clients 


are able to get some idea of the expected reliability. 


A commonly used metric for faults is the fault density, which is the estimated number of 
faults per 1000 lines of code (or kilo lines of code, KLOC). Faults are detected during 
the verification process and during normal use after the software has been put into 
productive use. Some faults are corrected beforehand and do not count towards the 
fault density. In addition to known and existing faults, there are faults that are present, 


yet undetected. 


Fault density figures are between 2 and 50 per KLOC. A figure of 2 is rated highly 


creditable. 


Experimental studies show that majority of faults rarely cause system failures while a 
small number of faults contribute to system failure. Thus, if this small figure can be 


traced and fixed, it would be most cost-effective. 


A major disadvantage of the fault density metric, as we have just seen, is that some 
bugs are more significant than others, which may also be difficult to detect. A more 
useful metric for this purpose could be Mean Time To Failure (MTTF). This is the 


average time for a system to perform without failing. This can be determined by logging 
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the times at which the system failures occur and calculating the average time between 


successive failures. This then allows to predict the future failure rate of the system. 


6.5 Software Quality 
How do you assert that you have developed good, quality software? There are two 


ways to identify it. Here they go: 


e Measuring the attributes of software that has been developed (quality control). 
e Monitoring and controlling the process of development of software (quality 


assurance). 
We can put in a commonly used definition of quality as follows: 


A product which fulfills and continues to fulfill the purpose for which it was developed Is 
a quality product. 


There is an alternative course of action. That is, at each stage of the development 
process, everything is in order. At each stage, we can correct a fault that has been 


done incorrectly. 
Here is a list of desirable software qualities: 


e Correctness- the extent to which the software meets its specification and meets its 
user’s requirements. 

e Reliability- the extent to which the software works without failing. 

e Performance- the amount of main memory and processor time that the software 
uses. 

e Integrity- the degree to which the software exercises control over access to 
information by users. 

e Usability- the ease of use of the software. 

e Maintainability- the effort required to find and fix a fault. 

e Flexibility- the effort required to change the software to meet the changed 


requirements. 
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e Testability- the effort required to test the software effectively. 

e Portability — the effort required to transfer the software to a different hardware 
and/or software platform. 

e Reusability- the extent to which the software (or its component) can be reused 
within another software. 

e Interoperability- the effort required to make the software work together with 
another software. 

e Security- the extent to which the software is safe from external sabotage that may 


damage and impair its use. 


Not every one of the above attributes may be required by any piece of software. 
Therefore, for each project, there arises a need to identify the required attributes 


before development can proceed. 
The above list of quality factors can be used in one or more of the following situations: 


1) At the initiation of software development for clarifying goals. 
2) During development to guiding the development process towards the goals. 


3) On completion, to assess the completed piece of software. 


The above qualitative attributes are only qualitative and not quantitative. Usually the 
purpose of metrics is to quantify desirable qualities. Thus, a quality measure such as, 
McCabe’s can used to measure maintainability. Reliability can be measured as MTTF. 
However, for many of these attributes it is hard to judge accurately and therefore, a 


subjective guess, with all its uncertainties, should be made. 


6.6 Quality Assurance 

Quality assurance means ensuring a software system meets its quality goals. The goals 
differ from one object to another. They must be clear and can be selected from the list 
of quality factors. To achieve its goals, a project must use effective tools and methods. 
Also checks during the development process must be carried out at every available 


opportunity to ensure that the process is being carried out correctly. 
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To make sure all the effective tools and methods are being used, the organization 
keeps track of its best practices and documents them in a quality manual. This is like a 
library of all the effective tools, methods and notations. On the overall, this manual 


describes all the standards and procedures that are available to be used. 


A standard defines a range, limit, tolerance or norm of some measurable attribute 
against which compliance is judged. For instance, during white box testing, every 


source code statement should be executed at least once. 


A procedure defines a way of doing things (rules, steps, guidelines, plans). For 
instance, black box testing, white box testing and a walkthrough must be used to verify 


each component of the software. 


To be effective, quality assurance must be planned ahead along with the planning of all 


other aspects of a software project. The project manager: 


1) Decides which quality factors are important for a project e.g., reliability, 
maintenance etc. 

2) Selects standards and procedures from the quality manual to meet quality goals of 
the project e.g., use of complexity metrics to check maintenance. 

3) Combines 1) and 2) into a quality assurance plan. It describes what procedures and 
standards should be used for the project, when they should be completed and who 


will execute them. 


An organization must not only use sound methods but also be seen to be using them. 
Therefore, a quality plan contains a number of quality controls. A quality control is an 
activity that checks whether the project's quality factors are achieved and records a 
documentary evidence. Depending on the quality factors of the project, quality controls 


should include the following functions as shown in Table 6.1. 
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Table 6.1: Functions of Quality Controls 


Action Document Factor being checked 


Collect a complexity metric Data on complexity Maintainability 
for each component in the system 


Component test 


Walkthrough to examine component Minutes of walkthrough 


for re-usability 





6.7 Process Development 

So far we have seen how quality can be measured, attained and ensured. For even 
better results, there may be a need to improve them. W. Edwards Deming, an 
influential management guru suggests that processes can be continuously improved. In 
his opinion, processes can be subjected to workers and the organization, which would 


look at them continuously for the sake of improving them. 


Deming insists that improvements on processes can be done indefinitely so that they 


benefit: 


1) Workers because they can control and take pride in their work. 
2) Organizations because they can make increased profits 


3) Customers because they get better quality. 


99 


CHAPTERZ7 


Project Management 


7.1 Introduction 

Project management is an activity trying to ensure that software development is 
successful. The meaning of success will differ from project to project, but it usually 
includes meeting the deadline, implementing the required features and meeting the 
budget. 


Project management aims to set up an orderly process so that a project runs smoothly 
from inception to completion but project management is difficult because software 


projects run late, are over budget and fail to meet user’s requirements. 
Why is a large-scale software project such a complex task? 


e It comprises a number of individual complex and interacting activities. 
e Itis usually carried out by large numbers of people over lengthy time spans. 
e It develops a complex product that conforms to predefined and strict requirements 


and standards. 


7.2 Project Inception 


At the start of a project, management requires the following tasks: 


1) Establishing the goals of the project: what is the deadline?, what are the priorities?, 
is it a highly reliable software?, and so on. 

2) Choosing a process model. 

3) Estimation: estimating the effort required, the duration of the project and its costs. 

4) Choosing appropriate methods and techniques so that they ensure that the software 
product attains its quality factors. 

5) Setting up and organizing the team so that the members can communicate 
effectively, carrying out different parts of the development work. 


6) Planning: Scheduling products, milestones, allocating people to the project. 
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As we have already defined, a process model is a model that serves as the plan or 
framework of the project. Individual tasks, tools and methods all fit within this skeleton 
of the project. We have described a number of models earlier in the book for instance, 
waterfall, incremental, prototyping, open source, agile methods and the unified process. 


The project manager can choose among these or create his own. 


Similarly, the project manager needs to select a package of tools and techniques that fit 
within the process model. For instance, he needs to decide about the choice of the 


programming language(s). 


Project Management usually involves monitoring and control. Monitoring tells what is 
happening. The control rectifies what is going wrong. In order to monitor, what is 
happening must be visible so that reliable information about the state of the 


development can be made available. 


Another important task involved with project management is people management- 
dealing with peoples’ needs and behavior. This concerns about motivating these people 


from time to time. 


7.3 Cost Estimation 


The most recent methods recognize that a number of factors affect the required effort 


during the software development process. These are: 


1) Size of the product 

2) Difficulty of the project 

3) Expertise of the developers 
4) Effectiveness of tools 


5) How much software can be reused from elsewhere. 


It is not until requirements analysis is complete that an estimate of the effort for the 
required project can be made. Even then there are too many uncertainties so that it is 
difficult to make an accurate estimate. It is only as the project progresses, the 


situations become clearer and more accurate estimates can be made. 
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Nevertheless, it becomes necessary at times to make an initial cost estimate so that a 
decision can be made about feasibility of the project. This is sometimes called 
investment appraisal or feasibility study. An estimate of the software development cost 
is compared with the financial value of the benefits that will occur. If the benefits are 
greater than the costs, the project will go ahead otherwise it is cancelled. Sometimes an 


estimate is difficult to make based on a crucial decision. 


Probably the best approach to cost estimates is function point analysis. It assumes that 
the effort required to develop a piece of software depends on what the software does 
that is, how many functions it implements. Function points are another name for use 
cases, which we mentioned at the end of chapter2. Two obvious problems arise with 
this approach. First, assigning the same weighting to various function points is very 
crude. Second, there are a wide variety of different productivity rates among 


developers. 


7.4 Selecting Tools and Methods 


What tools and methods would a project manager for a software development project 
select for use? How can he decide whether a particular method or tool is worth using? 


Any software development organization has expertise in particular tools and methods. It 
has also its own standards and procedures. These are huge investments. Thus, a 


project manager within an organization must adhere to its local methods and standards. 


If there is a scope to choose the techniques, a next step would be to establish a 
checklist of requirements and criteria. How important are factors such as cost, 


reliability, delivery date and ease of maintenance? 


When evaluating a technique, a generic checklist of criteria that can be used includes 


the following questions: 


e What are its special features and strengths? 
e What are its weaknesses? 


e What is its perspective? 
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e Is it systematic? 

e Can the technique be used in the particular application area? 

e What is the extent of the tool support? 

e What is the training time of the people who will use the method? 

e What is the level of skill required by the people who will use the method? 
e Does the method lead to maintainable software? 

e Does the method ensure that the software will meet performance targets? 
e What is its productivity? 

e How good is the reliability of the software who will use the technique? 

e Is good documentation automatically produced? 


e Is the method comfortable and exciting to use? 


While technical merits of development methods are important, sometimes practical 


considerations determine which development approach should be used. Examples are: 


e The computer facilities only support specific tools and techniques. 


e The price of software tools associated with a specific method. 


7.5 The Project Plan 


The project manager must create a plan that specifies: 


1) The deadline. 

2) Elaborate tasks. 

3) Intermediate Milestones. 

4) The outcomes at each stage. 

5) Who is involved and when? 

6) When are project reviews scheduled? 


7) The dependencies between the project stages. 


This plan takes into account the project plan, the total predicted effort, the tools and 


methods, the team organization and the expected deadline. The first important step is 
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to identify the major activities of the project. Next, the major activities are broken down 


into smaller tasks and figures for efforts assigned. 


The product of this planning is a detailed plan that shows all the activities that are 
required, the effort required for each and the dependencies among them. An example 


of a dependency could be the coding of a module that comes before testing it. 


There are notations, diagrams and tools that could help documenting a project plan. 
These are: 


1) Pert (Project Evaluation and Review Technique) shows activities and_ their 
interrelationships. 

2) Gantt Chart shows resources (people) and what they do. 

3) Microsoft Project is a software package designed to help in project planning and 
monitoring. 

4) A spreadsheet package can be used to describe a project plan, maintaining figures 


about the tasks, their likely and actual durations etc. 


7.6 Managing People 

Software is created by living, breathing people. However effective the tools and 
techniques, software development depends on the creativity of the developers. 
However well organized the team, there are informal processes at work — both 
individual and group. A project manager needs an awareness of these processes and 
needs to know what needs to be done to avoid weakening the team and what can be 


done to improve a team. 
First, some ways in which the management can weaken a team are: 


1) Show distrust of the team. 

2) Overemphasize the paperwork rather than creative thinking. 

3) Scatter the team members in different locations. 

4) Ask team members to work on a number of different projects (functional team), 


rather than focusing on a particular project (project team). 
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5) Press for earlier delivery at the cost of reducing the quality of the software. 
6) Set unrealistic deadlines 


7) Break up an effective team. 
Some management approaches for enhancing team activity are: 


1) Emphasize the quality of the software product. 

2) Plan for a number of successful milestones during the lifetime of the project. 
3) Emphasize how good the team is. 

4) Preserve a successful team for a subsequent project. 

5) Reduce hierarchy of the team. 


6) Create diversity within team members. 


105 


CHAPTERS 


Software Testing 


8.1 Introduction 

Testing is done to ensure that the software does what it is intended to do and to 
discover any defects the program has before it is put to use. When you test software, 
you execute a program using artificial data. You check the results of the test run for 


errors, anomalies and information about the program’s non-functional attributes. 
The testing process has two distinct goals: 


1) To demonstrate to the developer and customer that the software meets its 
requirements. For custom software, this means there will be at least one test for 
every requirement listed in the requirements document. For generic software 
products, there will be tests for all system features and for a combination of all the 
features that will be incorporated in the product release. 

2) To discover situations in which the behavior of the software is incorrect, undesirable 
and does not conform to its specification. These are the results of software defects. 
Defect testing roots out all undesirable system behavior such as system crashes, 
unwanted interactions with other systems, incorrect computations and data 


corruptions. 


The first goal leads to validation testing where you expect the system to perform 
correctly using a given set of test cases that reflect the system’s expected use. The 
second goal leads to defect testing where the test cases are designed to expose 
defects. During validation testing, you will find defects in the system. During defect 


testing, some of the tests will show that the program meets its requirements. 


Testing is a part of the broader process of verification and validation (V & V). 
Verification and validation ensure checking that the software meet its specification and 


delivers the functionality required by the customers paying for the software. The 
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checking processes start as soon as the requirements become available and continue 


through all stages of the software development process. 


The aim of verification is that the software meets its functional and non-functional 
requirements. Validation, on the other hand, is a more general process. The aim of 


validation is that the software meets its customer’s expectations. 


The ultimate goal of the verification and validation process is to establish confidence 
that the software is a good fit for the required purpose. The level of the required 
confidence depends on the system’s purpose, the expectations of the system users and 


the marketing environment for the system. 


1) Software purpose: The more critical the software, the more important that it is 
reliable. 

2) User expectations: As software matures, users expect it to become more reliable so 
that more thorough testing of later versions of the software may be required. 

3) Marketing Environment: When a system is marketed, the sellers of the system must 
take into account competing products, the price that customers are willing to pay for 


a system and the required schedule for delivering the system. 


Other than software testing, the verification and validation process also involves 
inspections and reviews. Inspections and reviews analyze and check the system 
requirements, design models, program source code sand even proposed system tests. 
The following figure shows inspections and testing. The arrows indicate the stages in 


the process where these techniques may be used. 
There are advantages of inspections over testing. These are: 


1) A single inspection session may uncover a lot of errors in the system because 
inspection is a static process and you dont have to be concerned about the 
interactions between errors. 


2) Incomplete versions of the system may be inspected without additional costs. 
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3) As well as searching for program defects, an inspection can also consider the 
broader quality attributes of a program such as the compliance with standards, 


portability and maintenance. 
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Fig. 8.1: Inspections and Testing 


However, inspections cannot replace software testing. Inspections are not good for 
discovering defects that arise because of unexpected interactions between different 
parts of a program, timing problems or problems with system performance. This is 


where testing and testing processes come into the picture. 


The following figure is an abstract model of the traditional testing process, suitable for 
plan-driven development. Test cases are input specifications to the test and output 
specifications (test results) from the test and including a statement of what is being 
tested. Test data and test execution can be automated but automatic test case 
generation is impossible as people who understand what the system is supposed to do 


must be involved to specify expected test results. 
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Fig. 8.2: A model of the software testing process 
Typically a commercial software system has to undergo three stages of testing: 


1) Development testing where the system is tested during development to discover 
bugs and defects. System designers and programmers are involved in the testing 
process. 

2) Release testing where a separate testing team tests a complete version of the 
system before it is released to the users. The objective of release testing is to check 
that the system meets the requirements of the clients. 

3) User testing where potential users test the system in their own environment who 


decide if the software can be released, marketed and sold. 


8.2 Development Test 

Development testing includes all testing activities carried out by the team developing 
the system. For critical systems a formal process is used with a separate testing group 
within the development team. They are responsible for developing tests and 


maintaining detailed records of test results. 
During development testing, it may be carried out at the following three levels: 


1) Unit testing where individual program units or object classes are tested. Unit testing 
should concentrate on functionality of objects or methods. 
2) Component testing where several individual units are integrated to create composite 


components. Component testing should focus on testing component interfaces. 


109 


3) System testing where some or all of the components are integrated and the system 


is tested as a whole. System testing should focus on testing component interactions. 


Development testing is actually a defect testing process where the aim is to discover 
bugs in the software. It is, therefore, interleaved with debugging which is the process 


of locating problems with the code and changing the program to fix these problems. 
8.2.1 Unit Testing 


Unit testing is the process of testing program components such as objects or methods 
classes. Individual methods and functions are the simplest type of components. Your 


tests should include calls to these routines with different input parameters. 


When you are testing object classes, your tests should cover all features of the object. 


This means you should: 


1) Test all operations associated with the object. 
2) Set and check all the attribute values associated with the object. 
3) Put the object into all the possible states. This means you should simulate all events 


that cause a state change. 


Whenever possible you should automate unit testing. An automated test has three 


parts: 


1) A setup part where you initialize the system with the test case namely, the inputs 
and expected outputs. 

2) A call part where you call the object or method to be tested. 

3) An assertion part where you compare the result of the call with the expected output. 
If the assertion has evaluated to be true, the test is a success otherwise it has 
failed. 


Sometimes objects can slow down the testing process. This is where the mock objects 
come into the picture. Mock objects are objects with the same interface as the external 


objects being used that simulate its functionality. Therefore, a mock object simulating a 
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database may have only a few linear data items organized in an array. So they can be 
accessed quickly without the overheads of calling the database and accessing disks, 


speeding up the test process unlike in the case of external objects. 
8.2.2 Choosing Unit Test Cases 


As testing is expensive and time consuming, it is important that you choose unit 


effective test cases. 
Two effective strategies that help you choose unit test cases are: 


1) Partition testing where you identify groups of inputs that have common 
characteristics and that should be processed in the same way. You should choose 
tests from within each of these groups. 

2) Guideline-based testing where you choose test cases based on testing guidelines. 
These guidelines include past experiences of programmers who made errors and 


mistakes while developing components and how they rectified them. 
8.2.3 Component Testing 


Software components are composite components that are made up of interacting 
objects. Software component testing should, therefore, focus on showing that the 
component interface behaves in accordance with its specification. You can assume that 


the unit tests on the individual objects within the component have been completed. 


There are different interfaces between program components and therefore, different 


types of interface errors can occur. These are: 


1) Parameter interfaces: These are interfaces in which data and function references are 
passed from one component to another. Methods in an object have a parameter 
interface. 

2) Shared Memory interfaces: These are interfaces in which a block of memory is 
shared between components. Data is placed in memory by one subsystem and 


retrieved from there by other subsystems. 
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3) Procedural interfaces: These are interfaces in which one component encapsulates a 
set of procedures that can be called by other components. Objects and reusable 
components have this type of interface. 

4) Message Passing interfaces: These are interfaces in which one component requests 
a service from another component by passing a message to it. A return message 
includes the results of executing the service. Some object-oriented interfaces such 


as, client-server systems have this type of interface. 


Interface errors are one of the most common sources of errors in complex systems. 


These errors fall into three types of classes: 


1) Interface use: A calling component calls another component and makes an error in 
the use of its interface. This type of error is common with parameter interfaces 
where parameters are of the wrong type, or passed in the wrong order, or the 
wrong number of parameters may be passed. 

2) Interface misunderstanding: A calling component misunderstands the specification 
of the interface of the called component and makes assumptions about its behavior. 
The called component may not behave as expected which then causes unexpected 
behavior in the calling component. For instance, the binary search method may be 
called with a parameter that is an unordered array. The search may then fail. 

3) Timing errors: These errors occur in real-time systems that use a shared memory or 
message-passing interface. The producer and consumer of data may operate at 
different speeds. Under these circumstances, the consumer of data may access out- 
of-date data because the producer of data has not updated data at the shared 


interface 
8.2.4 System Testing 


System testing involves integrating the components to create a version of the system 
and then testing the integrated system. System testing checks that components are 


compatible, interact correctly and transfer the right data at the right moment across 
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their interfaces. It obviously overlaps with component testing but there are two major 
differences: 


1) During system testing, reusable components that have been separately developed 
and off-the-shelf systems are integrated with newly developed components. The 
whole system is then tested. 

2) Components are developed by different team members or groups and may be 
integrated at this stage. System testing is a combined rather than an individual 
process. In some companies, system testing may be carried out by a separate 


testing team without involvement from the designers and programmers. 


System testing should focus on testing the interactions between components and 
objects that make up the system. This interaction testing should reveal component bugs 
when one component is used by other components in the system. Because of its focus 
on interaction testing, use case-based testing is an effective approach to system 
testing. Typically, each use case is implemented by several components or objects in 
the system. 


8.3 Test-Driven Development 

Test-driven development is an approach to program development in which you 
interleave testing and code development. In the process you develop code 
incrementally along with a test for that increment. You don’t move on to the next 
increment until you have tested the current increment. Test-driven development was 
developed as part of the agile processes such as Extreme Programming. However, it 


can be used in plan-driven development processes as well. 
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Fig. 8.3: Test-Driven Development Process 





The fundamental TDD process is shown in the above figure. The steps in the process 


are as follows: 


1) You should start identifying the increment of functionality that is required. This 
should normally be small and implementable in a few lines of code. 

2) You write a test for this functionality and implement this as an automated test. This 
means the test can be executed and will report whether it has passed or failed. 

3) You then run the test along with all other tests that have been implemented. Initially 
you have not implemented the increment and the new test will fail. This is deliberate 
as it shows the test adds something to the test set. 

4) You then implement the functionality and re-run the test. This means refactoring the 
existing code to improve it and add new code to what's already existing. 

5) Once all tests run successfully, you move on to implementing the next chunk of 


functionality. 
As well as better problem understanding, other benefits of test-driven development are: 


1. Code Coverage : Generally every code segment you write you should have at least 
one associated test. Therefore, you can be confident all of the code in the system 
has actually been executed. Code is tested as it is written. Therefore, defects are 


discovered early in the development process. 
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2. Regression Testing: A test suite is developed incrementally as a program is 
developed. You can always run regression tests so that changes to the program do 
not introduce new bugs. 

3. Simplified Debugging: When a test fails, it should be obvious where the test fails. 
The newly written code should be checked and modified. You don’t need to use 
debugging tools to locate the problem. 

4. System documentation: The tests themselves act as a form of documentation that 
describe what the program should be doing. Reading the tests make it easier to 


run the code. 


8.4 Release Testing 

Release testing is the process of testing a particular release of the system that is 
intended for use outside of the development team. Normally the system release is for 
customers and users. For software products, the release could be for product 


management who then prepares it for sale. 
There are two important differences between release testing and system testing: 


1) A separate team that has not been involved in the system development is 
responsible for release testing. 

2) System testing by the development team should focus on discovering the bugs in 
the system (defect testing). The objective of release testing is to check that the 
system meets its requirements and is good enough for external use (validation 


testing). 


The primary goal of the release testing process is to convince the supplier of the system 
that it is good enough for use. If yes, it can be released as a product or delivered to the 
customer. The release testing has to show that the system delivers its specified 
functionality, performance and reliability, and that it doesn’t fail during normal use. It 
should take into account all the system requirements, just not the requirements of the 


end users of the system. 
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8.4.1 Requirements-Based Testing 


A general principle of good requirements engineering practice is that requirements 
should be testable. A requirement should be written so that a test can be designed for 
it. A tester can check that the requirement has been satisfied. Requirements-based 
testing is a validation rather than defect testing — you are trying to validate that the 


system has adequately implemented its requirements. 


However, testing a requirement does not necessarily mean writing a single test. You 
normally have to write several tests to ensure that you have coverage of the 
requirement. In requirements-based testing you should also be able to link the tests to 


the specific requirements that are being tested. 
8.4.2 Scenario Testing 


Scenario testing is an approach to release testing where you devise typical scenarios of 
use and use these to develop test cases for the system. A scenario is a story, which 
describes one way in which the system might be used. Scenarios should be realistic and 
real system users should be able to relate to them. If you have used scenarios as part 
of the requirements engineering process, you may be able to use these as testing 


scenarios. 


When you use a _ scenario-based approach, you are normally testing several 
requirements within the same scenario. Therefore, along with checking individual 
requirements, you are also checking that combinations of requirements do not cause 


problems. 
8.4.3 Performance Testing 


Once a system has been completely integrated, it is possible to test for aroused 
properties such as, reliability and performance. Performance tests have to be carried 


out to ensure that the system can process its intended load. This usually involves 
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running a series of tests where you increase the load until the system performance 


becomes unacceptable. 


As with other testing, performance testing involves both with demonstrating that the 
system meets its requirements and discovering problems and defects in the system. To 
test whether the performance requirements are being achieved, you may have to create 
an operational profile. An operational profile is a series of tests that will reflect the 
actual mix of work handled by the system. Therefore, if 90% of the transactions are of 
type A, 5% of type B and the rest of types C, D and E, then you have to design the 
operational profile such that the vast majority of tests are of type A. Otherwise the test 


will not reflect the accurate operational performance of the system. 


This approach is not necessarily the best approach for defect testing. An effective way 
to discover the defects of the system is to design tests around the limits of the test. 
This test is known as stress testing. For example, to test 300 transactions per second, 
you start by testing the system fewer than 300 transactions per second and gradually 
increase the load beyond 300 transactions per second until the system fails. This type 


of testing has two functions: 


1) It tests the failure behavior of the system. Circumstances that may arise through an 
unexpected combination of events where the load placed on the system exceeds the 
maximum anticipated load. In these circumstances, system failure should not cause 
corruption of data or unexpected loss of user services. Stress testing checks that in 
these situations, the system fails soft rather than collapse under its load. 

2) It stresses the system so that the defects are forced to come to light, which would 


normally not be discovered. 


Stress testing is relevant to distributed networked systems. These systems often show 
degradation when they are heavily loaded. This is where stress testing comes to the 
picture because they help to discover when degradation begins in these systems so that 


you can add checks to the system to reject transactions beyond this limit. 


117 


8.5 User Testing 

User testing is that stage in the testing process in which users or customers provide 
input and advice on system testing. User testing is essential even when comprehensive 
system and release testing have been carried out. This is because influences from the 
user’s working environment have a major effect on the reliability, performance, usability 


and robustness of a system. 
In practice, there are three types of user testing: 


1) Alpha Testing: where users of the software work with the development team at the 
developer's site to test the software. 

2) Beta Testing: where a release of the software is made available to the users to allow 
them to experiment and raise problems that are discovered as they work with the 
system developers. 

3) Acceptance Testing: where customers test a system in order to decide whether it is 
ready to be accepted from the system developers and deployed in the customer 


environment. 


In alpha testing, users and developers work together to test a system as it is being 
developed. This means users can identify problems and issues that are not apparent to 
the development testing team. Developers can only work from the requirements but 
these do not necessarily reflect other factors that affect the practical use of the 
software. Users can, therefore, provide more information about practice leading to the 


design of more realistic tests. 


Beta testing becomes necessary when at times an unfinished version of the software 
system is made available to the customers and users for evaluation. Beta testers could 
be a selective group of customers who have adopted the system at the early stages. 
Alternatively, the software may be made available to the public so that anyone 
interested can use it for beta testing. Beta testing is, therefore, essential to discover 
interaction problems between the software and the features of the environment where 


it is used. 
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Acceptance testing is an inherent part of the custom systems development. It takes 


place after release testing. A customer formally tests the system to determine whether 


it should be accepted from the system developer on payment. There are six stages in 


the acceptance testing process. These are: 


1) 


2 


4 


3 


YY, 


4 


NY, 


5 


NY, 


6) 


Define acceptance criteria: This stage should take place earlier before the contract 
for the system is signed. The acceptance criteria should be part of the contract and 
agreed upon between the customer and developer. 

Plan acceptance testing: This involves deciding on the resources, time and budget 
for acceptance testing and establishing a testing schedule. The acceptance test plan 
should cover the requirements and maintain the order in which the system features 
are tested. It should define risks to the testing process such as system crashes and 
inadequate performance and how these risks can be rectified. 

Derive acceptance tests: Once acceptance criteria are defined, tests should be 
carried out to determine whether the system is acceptable. Acceptance tests should 
test both functional and non-functional (e.g., performance) characteristics of the 
system. 

Run acceptance tests: The agreed acceptance tests are executed on the system. 
Ideally, this should take place in the actual environment where the system will be 
used. Therefore, some training of the end users may be required. 

Negotiate test results: It is unlikely that all the defined acceptance tests on the 
system will pass and there will be no detected problems. Still, if this is the case, the 
acceptance testing is complete and the system can be handed over. More often than 
not, some problems will be revealed. In that case, the customer and developer have 
to negotiate to decide whether the system is good enough to put into use. 
Reject/accept system: This is a stage when developers and customer have a 
meeting to decide whether the system is okay to accept. In case it is not, further 
development is necessary to fix the detected problems. Acceptance testing should 


then be repeated once again after the problems have been solved. 
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In agile methods such as XP, the acceptance testing has a different meaning. In fact, 
the notion is users decide whether the system is acceptable. In XP, the user is part of 
the development team (who is an alpha tester) and provides the user requirements as 
user stories. They are responsible for defining tests which decide whether the 
developed system supports the user stories. The tests are automated and development 


does not proceed until the story acceptance tests have been passed. Therefore in XP, 


there is no scope for a separate acceptance testing activity. 
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Criteria Testing Tests Tests System 


Fig. 8.4: The Acceptance Testing Process 
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CHAPTERQY 


Software Evolution 


9.1 Introduction 

Software development does not stop after it has been delivered but continues 
throughout the lifetime of the system. After a system has been deployed, it has to 
change, for sure, if it has to remain useful. Business changes and changes to user 
expectations generate new requirements for the existing software. Parts of the software 
may have to be modified to correct errors that are found in operation, to adapt it for 
changes in its hardware and software platforms, and to improve its performance and 


other non-functional characteristics. 


Evolution of a system may rarely be considered in isolation. Changes to the 
environment lead to system change that may trigger further environment changes. Of 
course, the fact that systems have to evolve in a systems-rich environment often 
increases the difficulties and costs of evolution. In addition to understanding and 
analyzing the impact of a proposed change on the system itself, you may have to 
assess how this affects other systems in the operational environment. 


Software cost a lot of money so that a company has to use it for many years to get a 
return on the investment. Of course, requirements of the installed system change as 
the business and its environment change. Therefore, new releases of the systems, 


incorporating changes and updates, have to be created at regular intervals. 


You should, therefore, think of software engineering as a spiral process with 
requirements, design, implementation and testing going on throughout the lifetime of 
the system. You start by creating release1 of the system. Once delivered, changes are 
proposed and the development of release2 starts immediately. In fact, the need for 
evolution may become obvious even before the system is deployed so that later 
releases of the system may be under development before the current version is 


released. 
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This model of evolution implies that a single organization is responsible for both the 
initial development as well as the evolution of the software. Most packaged software 
products are developed using this approach. For custom software, a different approach 
is usually used. A company develops software for a customer and the customer’s own 
software development staff then takes over the system. Alternatively, the software 


customer can issue a contract to a different company for system support and evolution. 


Release 1 


~ a 2 


~~ - mien s 





Fig. 9.1: A Spiral Model of Development and Evolution 


In this case, there are likely to be discontinuities in the spiral process. Requirements 
and design documents may not be passed from one company to another. Companies 
may merge or reorganize and inherit software from other companies and then find this 
has to be changed. When the transition from development to evolution is not indefinite, 


the process of changing the software after delivery is called software maintenance. 


An alternate view of software evolution life cycle is shown below. In this view, evolution 


and servicing are distinguished. Evolution is the phase in which significant changes to 
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the software architecture and functionality are made. During servicing, the only 


changes that are made are relatively small, essential changes. 


’ fx 
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Fig. 9.2: Evolution and Servicing 


During evolution the software is used successfully and there is a constant stream of 
proposed requirements changes. However, as the software is modified, its structure 
starts to degrade and changes become more and more expensive. This happens after a 
few years of use when environmental changes, such as hardware and operating 
systems, are also required. At some stage in the life cycle, the software reaches a 
transition point where significant changes, implementing new requirements, become 


less costly. 


At that stage, the software moves from evolution to servicing. During the servicing 
phase, the software is still used but only tactical changes are made to it. During this 
stage, the company is usually considering about replacing the software. It is still used 
but at a final point, the phase-out, no further changes are made to it and so, users 


have to work around any problems they discover. 


9.2 Evolution Processes 

Software evolution processes vary depending on the type of software being maintained, 
the development processes used in an organization and the skills of people involved. In 
some organizations, evolution may be an informal process where change requests come 
from the conversations between system users and developers. In other companies, it is 
a formalized process with structured documentation produced at each stage in the 


process. 
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System change proposals are the driver for system evolution in all organizations. 
Change proposals may come from existing requirements that have not been 
implemented in the released system, requests for new requirements, bug reports from 
systems stakeholders and new ideas for software improvement from the software 
development team. The processes of change identification and system evolution are 


cyclic and continue throughout the lifetime of a system as shown in the following figure. 


Change identification } 
| Process IN 





1 





\ ( Software Evolution 7 


| b 
Process 








Fig. 9.3: Change identification and evolution processes 


Change proposals should be linked to components of the system that have to be 
modified to implement these systems. This allows the cost and impact of the change to 
be assessed. This is part of the general process of change management, which also 
should ensure that the correct versions of components are included in each system 


release. 


The following figure shows an overview of the evolution process. 
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Fig. 9.4: The software evolution process 


The process includes the fundamental activities of change analysis, release planning, 
system implementation and releasing a system to customers. The cost and impact of 
these changes are assessed to see how much of the system is affected by the change 
and how much it will cost to implement the change. If the proposed changes are 
accepted, a new release of the system is planned. During release planning, all proposed 
changes (fault repair, adaptation, new functionality) are considered. A decision is then 
made based on the changes which are to be implemented in the next version of the 
system. The changes are implemented and validated and a new version of the system is 
released. The process then iterates with a new set of changes proposed for the next 


release. 


You can think of the change implementation as an iteration of the development 
process, where revisions to the system are designed, implemented and _ tested. 
However, the critical difference is that the first stage of change implementation may 
involve understanding the program if the system developers are not responsible for the 
change implementation. During this program understanding phase, you have to 
understand how the program is structured, how it delivers the functionality of the 
program and how the proposed change might affect the program. You need this 
understanding to make sure that the proposed change does not cause new problems 
when it is introduced in the existing system. 
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Ideally, the change implementation of this process should modify the system 
specification, design and implementation to reflect the changes to the system as shown 
in Fig. 9.5 below. New requirements that reflect the system changes are proposed, 
analyzed and validated. System components are redesigned and implemented and the 
system is retested. If appropriate, prototyping of the proposed changes may be carried 


out as part of the change analysis process. 


During the evolution process, the requirements are analyzed in detail and implications 
of the changes emerge that were not apparent in the earlier stage analysis process. 
This means that the proposed changes may be modified and further customer 


discussions may be required before they are implemented. 


Change requests sometimes relate to system problems that have to be tackled urgently. 


These urgent changes can arise for three reasons: 


a) If a serious system fault occurs that has to be repaired to allow normal operation to 
continue. 

b) If changes to the system operating environment have unexpected effects that 
disrupt normal operation. 

c) If there are unanticipated changes to the business running the system such as the 
emergence of new competitors or the introduction of new legislation that affects the 


system. 


eae 


Proposed (Requirements \ ( Requirements Software ‘ 
Changes \ Analysis | \ Updating / \ Development / 





Fig. 9.5: Change Implementation 
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In these cases, the need to make the change quickly may mean you may not be able to 
follow the formal change process. Rather than modify the requirements and design, you 


make a quick emergency fix to the program to solve the immediate problem. This is 


illustrated in the following figure. 


Change ( i Analyze ‘ = Modify be, Deliver Modified »\ 
Requests \ Source Code y \_ Source Code y \____ System y 





Fig. 9.6: The emergency repair process 


However, the danger is that the requirements, design and code become inconsistent. 
Although you desire to document the change in requirements and design, further 
emergency fixes to the software may still be needed. These take priority over 
documentation. Ultimately, the original change is forgotten and the system 


documentation and code are never realigned. 


Emergency system repairs will have to be implemented as quickly as possible. You 
choose a quick and workable solution rather than the best solution as far as system 
structure is concerned. This accelerates the process of software ageing so that future 


changes gradually become even more difficult and maintenance costs increase. 


Agile methods and processes, as discussed in chapter 4, may be used for program 
evolution and program development. However, problems arise in situations where there 
is a handover from a development team to a separate team responsible for evolution. 


Two such problematic situations are: 


1) The development team has used agile methods but the evolution team prefers a 
plan-based approach. The evolution team may expect detailed documentation to 


support evolution but this is rarely done in an agile approach. 
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2) The development team has used a plan-based approach but the evolution team 
prefers agile methods. In this case, some reengineering may have to be done to 


improve the code before it can be used in an agile development process. 
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APPENDIX A: Case Studies 


Case Studies are designed to capture the reader’s interest. There are usually 
applications familiar to most readers. The cases could act as projects and could be 


carried out in parallel with studying the book. 
The cases we will discuss here are 


e The ATM 
e The Library 
e The Patient Monitoring System 


The ATM 


The ATM has a screen, a card reader, a small printer, a cash dispenser and a keyboard. 
The keyboard has numeric buttons, an enter key and a clear key. There are buttons on 
the sides of the screen to allow selection of any options displayed on the screen. The 


ATM is connected to the bank via a telephone line. 
The ATM provides facilities to 


e Dispense cash 


e Display the current balance 


The user must offer their card to the reader. The display then asks the user to enter 
their pin via the keyboard. If this is successful, the display offers a set of options to the 


user. 
The Library 


This application is a typical information system. Software is required to maintain 
information about books in the library, which is typically used by the library staff. The 


software must run on standard networked PC's. 


For each book, the following information is stored in the computer: 
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e Title 

e Author 

e ISBN 

e Year 

e Date of issue 


e Borrower identification 
The computer should be able to provide facilities to: 


e Issue a book to a borrower 
e Receive a book returned by a borrower 
e Create information about a newly acquired book 


e Display a list of books issued to a particular borrower 

The facilities should be accessible by a GUI (Graphical User Interface). 

The computer should respond within one second to any request. 

The system should provide a search facility to find out whether a book is available. 
When a book becomes overdue, the system should display appropriate information. 
Only the library staff should provide secured access to the system. 


The software should be delivered by a particular date and its cost should not be more 


than USD$100,000. It must be fully documented and easy to maintain. 
Patient Monitoring System 
This is an example of safety-critical system. 


A computer system maintains the vital signs of a patient in a hospital. Sensors attached 


to a patient continually send information to the computer: 


e Heart rate 


e Temperature 
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e Blood pressure 


The computer displays the information on a screen. It also logs the information in a file 
so that it can be retrieved and displayed. If any of the vital signs exceeds the safe 
limits, the computer screen flashes a warning and an alarm sounds. The limits have 
default values but can be changed by the operator. If any sensor fails, the screen 


flashes a warning and the alarm sounds. 
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APPENDIX B: UML Summary 


The Unified Modeling Language (UML) is a graphical notation for describing object 
oriented software. It is not a method for design but a notation that can help with 


designing software or help to document software after it is complete. 


This appendix only shows a part of the diagrams which belongs to a larger and more 


complex UML notation. We illustrate a little of the following diagrams here: 


e Use case diagrams 
e Class diagrams 
e Package diagrams 


e Activity diagrams 
B.1 Use Case Diagrams 


These diagrams describe, in outline, the use cases associated with a system. Figure B.1 
shows an example of a use case diagram for users of a bank ATM. In this diagram, 
there is a single type of user, a bank customer. A customer can ask the system to carry 


out either of the two functions: withdraw cash or check balance. 


withdraw cash 


Bank Customer 


check balance 





Fig. B.1: A Use Case Diagram 
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B.2 Class Diagrams 


These diagrams describe classes and their interrelationships. Classes are shown as 
rectangles containing the class name. The simplest relationship is where a class uses 
another. For example, in figure B.2, class Game uses the classes Defender, Alien, 
Laser and Bomb. This means the Game creates objects from these classes and calls 
methods in the objects created from these classes. 





Fig. B.2: A Class Diagram 


A class diagram can also show inheritance relationships between the classes: the 
subclasses and the super classes. As illustrated in figure B.3, to show that a class 
extends another, a line is drawn from the subclass to the superclass, with the 
arrowhead pointing to the superclass. Thus, Sprite is the superclass of both Alien and 
Bomb. 
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Fig. B.3: Class Diagram showing inheritance 


If a class is an abstract class, the name of the class is followed by the text {abstract} to 
clarify its meaning. 


An interface is described in the same way as a class in the form of a box. The 
difference is that the text <<interface>> precedes the name. A class that implements 
an interface has a dashed line with an arrowhead pointing to the interface box as 
shown in figure B.4. 





Fig. B.4: A Class and its interface. Arrow 
should be dashed 
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A class can be described in more detail, as described in Figure B.5. There are three 
compartments in this type of class diagram. The first compartment holds the class 
name, the second describes variables and the third describes methods. The visibility of 
an element can be described in a prefix as in Java: public, private, protected or default. 
In keeping with information hiding, the diagram is often drawn with the second 


compartment (the variables) omitted. 





Fig. B.5: Class diagram showing the 
details of a class 


B.3 Package Diagrams 


A package diagram can be as shown in Figure B.6. The package is a rectangle with a 
tab at the top that holds the package name. Optionally, the classes within the package 
can be shown within the rectangle. For instance, the figure shows the class util 


consisting of the classes Random, Stack and ArrayList within the package. 
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Random 


ArrayList 














Fig. B.6 : A Package Diagram 


B.4 Activity Diagrams 


An activity diagram consists of a sequence of activities. Thus, an activity diagram shows 


the flow of control through the software. An activity diagram can show: 


e Conditions (corresponding to if statements) 
e Loops (corresponding to if and while statements) 


e Concurrent activity (corresponding to threads) 


An activity diagram can also illustrate a human activity such as delivering a 
specification. Actions are written in boxes with curved corners. The sequence of actions 
is shown by the arrows. A sequence starts with a blob symbol and ends with a special 


different symbol as shown in Figure B.7 below. 


The diagram also uses the diamond-shaped branch symbol. Associated with each 
output from the branch is a condition. If the condition is true, the route is taken, just as 


in an if statement. 
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Draw up an outline 
specification 


Construct 
prototype 


Check with 
user 
Refine 
prototype 


[User requires change] 


[User happy] 


Deliver the 
specification 





Fig. B.7: An Activity Diagram showing the delivery of a 


specification 
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